[dpdk-dev] eal: postpone vdev initialization
Checks
Commit Message
Some platform like octeontx may use pci and
vdev based combined device to represent a logical
dpdk functional device.In such case, postponing the
vdev initialization after pci device
initialization will provide the better view of
the pci device resources in the system in
vdev's probe function, and it allows better
functional subsystem registration in vdev probe
function.
As a bonus, This patch fixes a bond device
initialization use case.
example command to reproduce the issue:
./testpmd -c 0x2 --vdev 'eth_bond0,mode=0,
slave=0000:02:00.0,slave=0000:03:00.0' --
--port-topology=chained
root cause:
In existing case(vdev initialization and then pci
initialization), creates three Ethernet ports with
following port ids
0 - Bond device
1 - PCI device 0
2 - PCI devive 1
Since testpmd, calls the configure/start on all the ports on
start up,it will translate to following illegal setup sequence
1)bond device configure/start
1.1) pci device0 stop/configure/start
1.2) pci device1 stop/configure/start
2)pci device 0 configure(illegal setup case,
as device in start state)
The fix changes the initialization sequence and
allow initialization in following valid setup order
1) pcie device 0 configure/start
2) pcie device 1 configure/start
3) bond device 2 configure/start
3.1) pcie device 0/stop/configure/start
3.2) pcie device 1/stop/configure/start
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
lib/librte_eal/bsdapp/eal/eal.c | 6 +++---
lib/librte_eal/linuxapp/eal/eal.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
Comments
On Sun, Nov 20, 2016 at 9:00 AM, Jerin Jacob
<jerin.jacob@caviumnetworks.com> wrote:
> Some platform like octeontx may use pci and
> vdev based combined device to represent a logical
> dpdk functional device.In such case, postponing the
> vdev initialization after pci device
> initialization will provide the better view of
> the pci device resources in the system in
> vdev's probe function, and it allows better
> functional subsystem registration in vdev probe
> function.
>
> As a bonus, This patch fixes a bond device
> initialization use case.
>
> example command to reproduce the issue:
> ./testpmd -c 0x2 --vdev 'eth_bond0,mode=0,
> slave=0000:02:00.0,slave=0000:03:00.0' --
> --port-topology=chained
>
> root cause:
> In existing case(vdev initialization and then pci
> initialization), creates three Ethernet ports with
> following port ids
> 0 - Bond device
> 1 - PCI device 0
> 2 - PCI devive 1
>
> Since testpmd, calls the configure/start on all the ports on
> start up,it will translate to following illegal setup sequence
>
> 1)bond device configure/start
> 1.1) pci device0 stop/configure/start
> 1.2) pci device1 stop/configure/start
> 2)pci device 0 configure(illegal setup case,
> as device in start state)
>
> The fix changes the initialization sequence and
> allow initialization in following valid setup order
> 1) pcie device 0 configure/start
> 2) pcie device 1 configure/start
> 3) bond device 2 configure/start
> 3.1) pcie device 0/stop/configure/start
> 3.2) pcie device 1/stop/configure/start
This patch is fine.
It's been a while since I looked at the bonding pmd.
I am just wondering if the bonding pmd should really start its slaves ports.
On Sunday 20 November 2016 01:30 PM, Jerin Jacob wrote:
> Some platform like octeontx may use pci and
> vdev based combined device to represent a logical
> dpdk functional device.In such case, postponing the
> vdev initialization after pci device
> initialization will provide the better view of
> the pci device resources in the system in
> vdev's probe function, and it allows better
> functional subsystem registration in vdev probe
> function.
>
> As a bonus, This patch fixes a bond device
> initialization use case.
>
> example command to reproduce the issue:
> ../testpmd -c 0x2 --vdev 'eth_bond0,mode=0,
> slave=0000:02:00.0,slave=0000:03:00.0' --
> --port-topology=chained
>
> root cause:
> In existing case(vdev initialization and then pci
> initialization), creates three Ethernet ports with
> following port ids
> 0 - Bond device
> 1 - PCI device 0
> 2 - PCI devive 1
>
> Since testpmd, calls the configure/start on all the ports on
> start up,it will translate to following illegal setup sequence
>
> 1)bond device configure/start
> 1.1) pci device0 stop/configure/start
> 1.2) pci device1 stop/configure/start
> 2)pci device 0 configure(illegal setup case,
> as device in start state)
>
> The fix changes the initialization sequence and
> allow initialization in following valid setup order
> 1) pcie device 0 configure/start
> 2) pcie device 1 configure/start
> 3) bond device 2 configure/start
> 3.1) pcie device 0/stop/configure/start
> 3.2) pcie device 1/stop/configure/start
>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> lib/librte_eal/bsdapp/eal/eal.c | 6 +++---
> lib/librte_eal/linuxapp/eal/eal.c | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
> index 35e3117..2206277 100644
> --- a/lib/librte_eal/bsdapp/eal/eal.c
> +++ b/lib/librte_eal/bsdapp/eal/eal.c
> @@ -577,9 +577,6 @@ rte_eal_init(int argc, char **argv)
> rte_config.master_lcore, thread_id, cpuset,
> ret == 0 ? "" : "...");
>
> - if (rte_eal_dev_init() < 0)
> - rte_panic("Cannot init pmd devices\n");
> -
> RTE_LCORE_FOREACH_SLAVE(i) {
>
> /*
> @@ -616,6 +613,9 @@ rte_eal_init(int argc, char **argv)
> if (rte_eal_pci_probe())
> rte_panic("Cannot probe PCI\n");
>
> + if (rte_eal_dev_init() < 0)
> + rte_panic("Cannot init pmd devices\n");
> +
> rte_eal_mcfg_complete();
>
> return fctret;
> diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
> index 2075282..16dd5b9 100644
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -841,9 +841,6 @@ rte_eal_init(int argc, char **argv)
> rte_config.master_lcore, (int)thread_id, cpuset,
> ret == 0 ? "" : "...");
>
> - if (rte_eal_dev_init() < 0)
> - rte_panic("Cannot init pmd devices\n");
> -
> if (rte_eal_intr_init() < 0)
> rte_panic("Cannot init interrupt-handling thread\n");
>
> @@ -887,6 +884,9 @@ rte_eal_init(int argc, char **argv)
> if (rte_eal_pci_probe())
> rte_panic("Cannot probe PCI\n");
>
> + if (rte_eal_dev_init() < 0)
> + rte_panic("Cannot init pmd devices\n");
> +
> rte_eal_mcfg_complete();
>
> return fctret;
>
Movement looks fine to me.
IMO, rte_eal_dev_init() is a misleading name. It actually performs a
driver->probe for vdev - which is parallel to rte_eal_pci_probe.
-
Shreyansh
On 11/20/2016 8:00 AM, Jerin Jacob wrote:
> Some platform like octeontx may use pci and
> vdev based combined device to represent a logical
> dpdk functional device.In such case, postponing the
> vdev initialization after pci device
> initialization will provide the better view of
> the pci device resources in the system in
> vdev's probe function, and it allows better
> functional subsystem registration in vdev probe
> function.
>
> As a bonus, This patch fixes a bond device
> initialization use case.
>
> example command to reproduce the issue:
> ./testpmd -c 0x2 --vdev 'eth_bond0,mode=0,
> slave=0000:02:00.0,slave=0000:03:00.0' --
> --port-topology=chained
>
> root cause:
> In existing case(vdev initialization and then pci
> initialization), creates three Ethernet ports with
> following port ids
> 0 - Bond device
> 1 - PCI device 0
> 2 - PCI devive 1
>
> Since testpmd, calls the configure/start on all the ports on
> start up,it will translate to following illegal setup sequence
>
> 1)bond device configure/start
> 1.1) pci device0 stop/configure/start
> 1.2) pci device1 stop/configure/start
> 2)pci device 0 configure(illegal setup case,
> as device in start state)
>
> The fix changes the initialization sequence and
> allow initialization in following valid setup order
> 1) pcie device 0 configure/start
> 2) pcie device 1 configure/start
> 3) bond device 2 configure/start
> 3.1) pcie device 0/stop/configure/start
> 3.2) pcie device 1/stop/configure/start
>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
This changes the port id assignments to the devices, right?
Previously virtual devices get first available port ids (0..N1), later
physical devices (N1..N2). Now this becomes reverse.
Can this change break some existing user applications?
Thanks,
ferruh
On Mon, Nov 21, 2016 at 10:39:00AM +0530, Shreyansh Jain wrote:
> On Sunday 20 November 2016 01:30 PM, Jerin Jacob wrote:
> > Some platform like octeontx may use pci and
> > vdev based combined device to represent a logical
> > dpdk functional device.In such case, postponing the
> > vdev initialization after pci device
> > initialization will provide the better view of
> > the pci device resources in the system in
> > vdev's probe function, and it allows better
> > functional subsystem registration in vdev probe
> > function.
> >
> > As a bonus, This patch fixes a bond device
> > initialization use case.
> >
> > example command to reproduce the issue:
> > ../testpmd -c 0x2 --vdev 'eth_bond0,mode=0,
> > slave=0000:02:00.0,slave=0000:03:00.0' --
> > --port-topology=chained
> >
> > root cause:
> > In existing case(vdev initialization and then pci
> > initialization), creates three Ethernet ports with
> > following port ids
> > 0 - Bond device
> > 1 - PCI device 0
> > 2 - PCI devive 1
> >
> > Since testpmd, calls the configure/start on all the ports on
> > start up,it will translate to following illegal setup sequence
> >
> > 1)bond device configure/start
> > 1.1) pci device0 stop/configure/start
> > 1.2) pci device1 stop/configure/start
> > 2)pci device 0 configure(illegal setup case,
> > as device in start state)
> >
> > The fix changes the initialization sequence and
> > allow initialization in following valid setup order
> > 1) pcie device 0 configure/start
> > 2) pcie device 1 configure/start
> > 3) bond device 2 configure/start
> > 3.1) pcie device 0/stop/configure/start
> > 3.2) pcie device 1/stop/configure/start
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> > lib/librte_eal/bsdapp/eal/eal.c | 6 +++---
> > lib/librte_eal/linuxapp/eal/eal.c | 6 +++---
> > 2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
> > index 35e3117..2206277 100644
> > --- a/lib/librte_eal/bsdapp/eal/eal.c
> > +++ b/lib/librte_eal/bsdapp/eal/eal.c
> > @@ -577,9 +577,6 @@ rte_eal_init(int argc, char **argv)
> > rte_config.master_lcore, thread_id, cpuset,
> > ret == 0 ? "" : "...");
> >
> > - if (rte_eal_dev_init() < 0)
> > - rte_panic("Cannot init pmd devices\n");
> > -
> > RTE_LCORE_FOREACH_SLAVE(i) {
> >
> > /*
> > @@ -616,6 +613,9 @@ rte_eal_init(int argc, char **argv)
> > if (rte_eal_pci_probe())
> > rte_panic("Cannot probe PCI\n");
> >
> > + if (rte_eal_dev_init() < 0)
> > + rte_panic("Cannot init pmd devices\n");
> > +
> > rte_eal_mcfg_complete();
> >
> > return fctret;
> > diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
> > index 2075282..16dd5b9 100644
> > --- a/lib/librte_eal/linuxapp/eal/eal.c
> > +++ b/lib/librte_eal/linuxapp/eal/eal.c
> > @@ -841,9 +841,6 @@ rte_eal_init(int argc, char **argv)
> > rte_config.master_lcore, (int)thread_id, cpuset,
> > ret == 0 ? "" : "...");
> >
> > - if (rte_eal_dev_init() < 0)
> > - rte_panic("Cannot init pmd devices\n");
> > -
> > if (rte_eal_intr_init() < 0)
> > rte_panic("Cannot init interrupt-handling thread\n");
> >
> > @@ -887,6 +884,9 @@ rte_eal_init(int argc, char **argv)
> > if (rte_eal_pci_probe())
> > rte_panic("Cannot probe PCI\n");
> >
> > + if (rte_eal_dev_init() < 0)
> > + rte_panic("Cannot init pmd devices\n");
> > +
> > rte_eal_mcfg_complete();
> >
> > return fctret;
> >
>
> Movement looks fine to me.
>
> IMO, rte_eal_dev_init() is a misleading name. It actually performs a
> driver->probe for vdev - which is parallel to rte_eal_pci_probe.
Looks good to me. If there are no objection, I can change to rte_eal_vdev_probe()
as a separate patch in v2. Let the order change patch be separate.
>
> -
> Shreyansh
On Mon, Nov 21, 2016 at 09:54:57AM +0000, Ferruh Yigit wrote:
> On 11/20/2016 8:00 AM, Jerin Jacob wrote:
> > Some platform like octeontx may use pci and
> > vdev based combined device to represent a logical
> > dpdk functional device.In such case, postponing the
> > vdev initialization after pci device
> > initialization will provide the better view of
> > the pci device resources in the system in
> > vdev's probe function, and it allows better
> > functional subsystem registration in vdev probe
> > function.
> >
> > As a bonus, This patch fixes a bond device
> > initialization use case.
> >
> > example command to reproduce the issue:
> > ./testpmd -c 0x2 --vdev 'eth_bond0,mode=0,
> > slave=0000:02:00.0,slave=0000:03:00.0' --
> > --port-topology=chained
> >
> > root cause:
> > In existing case(vdev initialization and then pci
> > initialization), creates three Ethernet ports with
> > following port ids
> > 0 - Bond device
> > 1 - PCI device 0
> > 2 - PCI devive 1
> >
> > Since testpmd, calls the configure/start on all the ports on
> > start up,it will translate to following illegal setup sequence
> >
> > 1)bond device configure/start
> > 1.1) pci device0 stop/configure/start
> > 1.2) pci device1 stop/configure/start
> > 2)pci device 0 configure(illegal setup case,
> > as device in start state)
> >
> > The fix changes the initialization sequence and
> > allow initialization in following valid setup order
> > 1) pcie device 0 configure/start
> > 2) pcie device 1 configure/start
> > 3) bond device 2 configure/start
> > 3.1) pcie device 0/stop/configure/start
> > 3.2) pcie device 1/stop/configure/start
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
>
> This changes the port id assignments to the devices, right?
>
> Previously virtual devices get first available port ids (0..N1), later
> physical devices (N1..N2). Now this becomes reverse.
>
> Can this change break some existing user applications?
I guess it may be effected only to ethdev bond pmd based application,
which is broken anyway.
Let me know what it takes to make forward progress on this patch. I can
fix the same in v2.
Jerin
On 11/21/2016 5:02 PM, Jerin Jacob wrote:
> On Mon, Nov 21, 2016 at 09:54:57AM +0000, Ferruh Yigit wrote:
>> On 11/20/2016 8:00 AM, Jerin Jacob wrote:
>>> Some platform like octeontx may use pci and
>>> vdev based combined device to represent a logical
>>> dpdk functional device.In such case, postponing the
>>> vdev initialization after pci device
>>> initialization will provide the better view of
>>> the pci device resources in the system in
>>> vdev's probe function, and it allows better
>>> functional subsystem registration in vdev probe
>>> function.
>>>
>>> As a bonus, This patch fixes a bond device
>>> initialization use case.
>>>
>>> example command to reproduce the issue:
>>> ./testpmd -c 0x2 --vdev 'eth_bond0,mode=0,
>>> slave=0000:02:00.0,slave=0000:03:00.0' --
>>> --port-topology=chained
>>>
>>> root cause:
>>> In existing case(vdev initialization and then pci
>>> initialization), creates three Ethernet ports with
>>> following port ids
>>> 0 - Bond device
>>> 1 - PCI device 0
>>> 2 - PCI devive 1
>>>
>>> Since testpmd, calls the configure/start on all the ports on
>>> start up,it will translate to following illegal setup sequence
>>>
>>> 1)bond device configure/start
>>> 1.1) pci device0 stop/configure/start
>>> 1.2) pci device1 stop/configure/start
>>> 2)pci device 0 configure(illegal setup case,
>>> as device in start state)
>>>
>>> The fix changes the initialization sequence and
>>> allow initialization in following valid setup order
>>> 1) pcie device 0 configure/start
>>> 2) pcie device 1 configure/start
>>> 3) bond device 2 configure/start
>>> 3.1) pcie device 0/stop/configure/start
>>> 3.2) pcie device 1/stop/configure/start
>>>
>>> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>>> ---
>>
>> This changes the port id assignments to the devices, right?
>>
>> Previously virtual devices get first available port ids (0..N1), later
>> physical devices (N1..N2). Now this becomes reverse.
>>
>> Can this change break some existing user applications?
>
> I guess it may be effected only to ethdev bond pmd based application,
> which is broken anyway.
My concern is, this may effect the applications that use "--vdev" eal
parameter and has an assumption about port assignment.
And if this breaks any userspace application, does it require a
deprecation notice?
> Let me know what it takes to make forward progress on this patch. I can
> fix the same in v2.
>
> Jerin
>
On Mon, Nov 21, 2016 at 05:35:58PM +0000, Ferruh Yigit wrote:
> On 11/21/2016 5:02 PM, Jerin Jacob wrote:
> > On Mon, Nov 21, 2016 at 09:54:57AM +0000, Ferruh Yigit wrote:
> >> On 11/20/2016 8:00 AM, Jerin Jacob wrote:
> >>> Some platform like octeontx may use pci and
> >>> vdev based combined device to represent a logical
> >>> dpdk functional device.In such case, postponing the
> >>> vdev initialization after pci device
> >>> initialization will provide the better view of
> >>> the pci device resources in the system in
> >>> vdev's probe function, and it allows better
> >>> functional subsystem registration in vdev probe
> >>> function.
> >>>
> >>> As a bonus, This patch fixes a bond device
> >>> initialization use case.
> >>>
> >>> example command to reproduce the issue:
> >>> ./testpmd -c 0x2 --vdev 'eth_bond0,mode=0,
> >>> slave=0000:02:00.0,slave=0000:03:00.0' --
> >>> --port-topology=chained
> >>>
> >>> root cause:
> >>> In existing case(vdev initialization and then pci
> >>> initialization), creates three Ethernet ports with
> >>> following port ids
> >>> 0 - Bond device
> >>> 1 - PCI device 0
> >>> 2 - PCI devive 1
> >>>
> >>> Since testpmd, calls the configure/start on all the ports on
> >>> start up,it will translate to following illegal setup sequence
> >>>
> >>> 1)bond device configure/start
> >>> 1.1) pci device0 stop/configure/start
> >>> 1.2) pci device1 stop/configure/start
> >>> 2)pci device 0 configure(illegal setup case,
> >>> as device in start state)
> >>>
> >>> The fix changes the initialization sequence and
> >>> allow initialization in following valid setup order
> >>> 1) pcie device 0 configure/start
> >>> 2) pcie device 1 configure/start
> >>> 3) bond device 2 configure/start
> >>> 3.1) pcie device 0/stop/configure/start
> >>> 3.2) pcie device 1/stop/configure/start
> >>>
> >>> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> >>> ---
> >>
> >> This changes the port id assignments to the devices, right?
> >>
> >> Previously virtual devices get first available port ids (0..N1), later
> >> physical devices (N1..N2). Now this becomes reverse.
> >>
> >> Can this change break some existing user applications?
> >
> > I guess it may be effected only to ethdev bond pmd based application,
> > which is broken anyway.
>
> My concern is, this may effect the applications that use "--vdev" eal
> parameter and has an assumption about port assignment.
Not sure. Application expectation on specific port assignment is bad anyway.
But in any event, what we do with exiting ethdev bond pmd failure.
>
> And if this breaks any userspace application, does it require a
> deprecation notice?
I am not sure. Thomas, Any input on this ?
>
> > Let me know what it takes to make forward progress on this patch. I can
> > fix the same in v2.
> >
> > Jerin
> >
>
2016-11-23 05:37, Jerin Jacob:
> On Mon, Nov 21, 2016 at 05:35:58PM +0000, Ferruh Yigit wrote:
> > On 11/21/2016 5:02 PM, Jerin Jacob wrote:
> > > On Mon, Nov 21, 2016 at 09:54:57AM +0000, Ferruh Yigit wrote:
> > >> This changes the port id assignments to the devices, right?
> > >>
> > >> Previously virtual devices get first available port ids (0..N1), later
> > >> physical devices (N1..N2). Now this becomes reverse.
> > >>
> > >> Can this change break some existing user applications?
> > >
> > > I guess it may be effected only to ethdev bond pmd based application,
> > > which is broken anyway.
> >
> > My concern is, this may effect the applications that use "--vdev" eal
> > parameter and has an assumption about port assignment.
>
> Not sure. Application expectation on specific port assignment is bad anyway.
> But in any event, what we do with exiting ethdev bond pmd failure.
>
> >
> > And if this breaks any userspace application, does it require a
> > deprecation notice?
>
> I am not sure. Thomas, Any input on this ?
Is the expectation thought by Ferruh, written somewhere?
If not, we can accept this change as is in this release.
v2:
- No changes in eal: postpone vdev initialization
- Added new patch "eal: rename dev init API for consistency" as
suggested by Shreyansh Jain
http://dpdk.org/dev/patchwork/patch/17096/
Jerin Jacob (2):
eal: postpone vdev initialization
eal: rename dev init API for consistency
drivers/net/virtio/virtio_user_ethdev.c | 2 +-
lib/librte_eal/bsdapp/eal/eal.c | 6 ++---
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 +-
lib/librte_eal/common/eal_common_dev.c | 29 -------------------------
lib/librte_eal/common/eal_common_vdev.c | 29 +++++++++++++++++++++++++
lib/librte_eal/common/include/rte_dev.h | 4 ++--
lib/librte_eal/linuxapp/eal/eal.c | 6 ++---
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 2 +-
8 files changed, 40 insertions(+), 40 deletions(-)
As previously discussed in RFC v1 [1], RFC v2 [2], with changes
described in [3] (also pasted below), here is the first non-draft series
for this new API.
[1] http://dpdk.org/ml/archives/dev/2016-August/045181.html
[2] http://dpdk.org/ml/archives/dev/2016-October/048592.html
[3] http://dpdk.org/ml/archives/dev/2016-October/048196.html
v2..v3:
1) Changed struct rte_event layout more aligment balanced(Harry, Jerin)
2) Changed event_ptr type to void* from uintptr_t(Bruce)
3) Changed ev[] as const in rte_event_enqueue_burst to disallow
drivers from modifying the events passed in(Bruce)
4) Removed queue memory allocation from common code as some drivers may not need
it(Bruce)
5) Removed "struct rte_event_queue_link" and replaced with queues and priorities
in the link and link_get API to avoid one redirection to use the API(Bruce)
v1..v2:
1) Remove unnecessary header files from rte_eventdev.h(Thomas)
2) Removed PMD driver name(EVENTDEV_NAME_SKELETON_PMD) from rte_eventdev.h(Thomas)
3) Removed different #define for different priority schemes. Changed to
one event device RTE_EVENT_DEV_PRIORITY_* priority (Bruce)
4) add const to rte_event_dev_configure(), rte_event_queue_setup(),
rte_event_port_setup(), rte_event_port_link()(Bruce)
5) Fixed missing dev argument in dev->schedule() function(Bruce)
6) Changed \see to @see in doxgen comments(Thomas)
7) Added additional text in specification to clarify the queue depth(Thomas)
8) Changed wait to timeout across the specification(Thomas)
9) Added longer explanation for RTE_EVENT_OP_NEW and RTE_EVENT_OP_FORWARD(Thomas)
10) Fixed issue with RTE_EVENT_OP_RELEASE doxgen formatting(Thomas)
11) Changed to RTE_EVENT_DEV_CFG_FLAG_ from RTE_EVENT_DEV_CFG_(Thomas)
12) Changed to EVENT_QUEUE_CFG_FLAG_ from EVENT_QUEUE_CFG_(Thomas)
13) s/RTE_EVENT_TYPE_CORE/RTE_EVENT_TYPE_CPU/(Thomas, Gage)
14) Removed non burst API and kept only the burst API in the API specification
(Thomas, Bruce, Harry, Jerin)
-- Driver interface has non burst API, selection of the non burst API is based
on num_objects == 1
15) sizeeof(struct rte_event) was not 16 in v1. Fixed it in v2
-- reduced the width of event_type to 4bit to save space for future change
-- introduced impl_opaque for implementation specific opaque data(Harry),
Something useful for HW driver too, in the context of removal the need for sepeare
release API.
-- squashed other element size and provided enough space to impl_opaque(Jerin)
-- added RTE_BUILD_BUG_ON(sizeof(struct rte_event) != 16); check
16) add union of uint64_t in the second element in struct rte_event to
make sure the structure has 16byte address all arch(Thomas)
17) Fixed invalid check of nb_atomic_order_sequences in implementation(Gage)
18) s/EDEV_LOG_ERR/RTE_EDEV_LOG_ERR(Thomas)
19) s/rte_eventdev_pmd_/rte_event_pmd_/(Bruce)
20) added fine details of distributed vs centralized scheduling information
in the specification and introduced RTE_EVENT_DEV_CAP_FLAG_DISTRIBUTED_SCHED
flag(Gage)
21)s/RTE_EVENT_QUEUE_CFG_FLAG_SINGLE_CONSUMER/RTE_EVENT_QUEUE_CFG_FLAG_SINGLE_LINK (Jerin)
to remove the confusion to between another producer and consumer in sw eventdev driver
22) Northbound api implementation patch spited to more logical patches(Thomas)
Changes since RFC v2:
- Updated the documentation to define the need for this library[Jerin]
- Added RTE_EVENT_QUEUE_CFG_*_ONLY configuration parameters in
struct rte_event_queue_conf to enable optimized sw implementation [Bruce]
- Introduced RTE_EVENT_OP* ops [Bruce]
- Added nb_event_queue_flows,nb_event_port_dequeue_depth, nb_event_port_enqueue_depth
in rte_event_dev_configure() like ethdev and crypto library[Jerin]
- Removed rte_event_release() and replaced with RTE_EVENT_OP_RELEASE ops to
reduce fast path APIs and it is redundant too[Jerin]
- In the view of better application portability, Removed pin_event
from rte_event_enqueue as it is just hint and Intel/NXP can not support it[Jerin]
- Added rte_event_port_links_get()[Jerin]
- Added rte_event_dev_dump[Harry]
Notes:
- This patch set is check-patch clean with an exception that
03/06 has one WARNING:MACRO_WITH_FLOW_CONTROL
- Looking forward to getting additional maintainers for libeventdev
TODO:
1) Create user guide
Jerin Jacob (6):
eventdev: introduce event driven programming model
eventdev: define southbound driver interface
eventdev: implement the northbound APIs
eventdev: implement PMD registration functions
event/skeleton: add skeleton eventdev driver
app/test: unit test case for eventdev APIs
MAINTAINERS | 5 +
app/test/Makefile | 2 +
app/test/test_eventdev.c | 778 +++++++++++
config/common_base | 14 +
doc/api/doxy-api-index.md | 1 +
doc/api/doxy-api.conf | 1 +
drivers/Makefile | 1 +
drivers/event/Makefile | 36 +
drivers/event/skeleton/Makefile | 55 +
.../skeleton/rte_pmd_skeleton_event_version.map | 4 +
drivers/event/skeleton/skeleton_eventdev.c | 518 +++++++
drivers/event/skeleton/skeleton_eventdev.h | 68 +
lib/Makefile | 1 +
lib/librte_eal/common/include/rte_log.h | 1 +
lib/librte_eventdev/Makefile | 57 +
lib/librte_eventdev/rte_eventdev.c | 1220 +++++++++++++++++
lib/librte_eventdev/rte_eventdev.h | 1407 ++++++++++++++++++++
lib/librte_eventdev/rte_eventdev_pmd.h | 511 +++++++
lib/librte_eventdev/rte_eventdev_version.map | 39 +
mk/rte.app.mk | 5 +
20 files changed, 4724 insertions(+)
create mode 100644 app/test/test_eventdev.c
create mode 100644 drivers/event/Makefile
create mode 100644 drivers/event/skeleton/Makefile
create mode 100644 drivers/event/skeleton/rte_pmd_skeleton_event_version.map
create mode 100644 drivers/event/skeleton/skeleton_eventdev.c
create mode 100644 drivers/event/skeleton/skeleton_eventdev.h
create mode 100644 lib/librte_eventdev/Makefile
create mode 100644 lib/librte_eventdev/rte_eventdev.c
create mode 100644 lib/librte_eventdev/rte_eventdev.h
create mode 100644 lib/librte_eventdev/rte_eventdev_pmd.h
create mode 100644 lib/librte_eventdev/rte_eventdev_version.map
My mail reader (thunderbird) is showing this series as a thread of "eal:
postpone vdev initialization" patch series. Is it just me?
If it is a wrong 'in-reply-to', I think it should be corrected or people
might not be able to search for this under right thread.
On Sunday 18 December 2016 07:51 PM, Jerin Jacob wrote:
> As previously discussed in RFC v1 [1], RFC v2 [2], with changes
> described in [3] (also pasted below), here is the first non-draft series
> for this new API.
>
> [1] http://dpdk.org/ml/archives/dev/2016-August/045181.html
> [2] http://dpdk.org/ml/archives/dev/2016-October/048592.html
> [3] http://dpdk.org/ml/archives/dev/2016-October/048196.html
>
> v2..v3:
>
> 1) Changed struct rte_event layout more aligment balanced(Harry, Jerin)
> 2) Changed event_ptr type to void* from uintptr_t(Bruce)
> 3) Changed ev[] as const in rte_event_enqueue_burst to disallow
> drivers from modifying the events passed in(Bruce)
> 4) Removed queue memory allocation from common code as some drivers may not need
> it(Bruce)
> 5) Removed "struct rte_event_queue_link" and replaced with queues and priorities
> in the link and link_get API to avoid one redirection to use the API(Bruce)
>
> v1..v2:
> 1) Remove unnecessary header files from rte_eventdev.h(Thomas)
> 2) Removed PMD driver name(EVENTDEV_NAME_SKELETON_PMD) from rte_eventdev.h(Thomas)
> 3) Removed different #define for different priority schemes. Changed to
> one event device RTE_EVENT_DEV_PRIORITY_* priority (Bruce)
> 4) add const to rte_event_dev_configure(), rte_event_queue_setup(),
> rte_event_port_setup(), rte_event_port_link()(Bruce)
> 5) Fixed missing dev argument in dev->schedule() function(Bruce)
> 6) Changed \see to @see in doxgen comments(Thomas)
> 7) Added additional text in specification to clarify the queue depth(Thomas)
> 8) Changed wait to timeout across the specification(Thomas)
> 9) Added longer explanation for RTE_EVENT_OP_NEW and RTE_EVENT_OP_FORWARD(Thomas)
> 10) Fixed issue with RTE_EVENT_OP_RELEASE doxgen formatting(Thomas)
> 11) Changed to RTE_EVENT_DEV_CFG_FLAG_ from RTE_EVENT_DEV_CFG_(Thomas)
> 12) Changed to EVENT_QUEUE_CFG_FLAG_ from EVENT_QUEUE_CFG_(Thomas)
> 13) s/RTE_EVENT_TYPE_CORE/RTE_EVENT_TYPE_CPU/(Thomas, Gage)
> 14) Removed non burst API and kept only the burst API in the API specification
> (Thomas, Bruce, Harry, Jerin)
> -- Driver interface has non burst API, selection of the non burst API is based
> on num_objects == 1
> 15) sizeeof(struct rte_event) was not 16 in v1. Fixed it in v2
> -- reduced the width of event_type to 4bit to save space for future change
> -- introduced impl_opaque for implementation specific opaque data(Harry),
> Something useful for HW driver too, in the context of removal the need for sepeare
> release API.
> -- squashed other element size and provided enough space to impl_opaque(Jerin)
> -- added RTE_BUILD_BUG_ON(sizeof(struct rte_event) != 16); check
> 16) add union of uint64_t in the second element in struct rte_event to
> make sure the structure has 16byte address all arch(Thomas)
> 17) Fixed invalid check of nb_atomic_order_sequences in implementation(Gage)
> 18) s/EDEV_LOG_ERR/RTE_EDEV_LOG_ERR(Thomas)
> 19) s/rte_eventdev_pmd_/rte_event_pmd_/(Bruce)
> 20) added fine details of distributed vs centralized scheduling information
> in the specification and introduced RTE_EVENT_DEV_CAP_FLAG_DISTRIBUTED_SCHED
> flag(Gage)
> 21)s/RTE_EVENT_QUEUE_CFG_FLAG_SINGLE_CONSUMER/RTE_EVENT_QUEUE_CFG_FLAG_SINGLE_LINK (Jerin)
> to remove the confusion to between another producer and consumer in sw eventdev driver
> 22) Northbound api implementation patch spited to more logical patches(Thomas)
>
> Changes since RFC v2:
>
> - Updated the documentation to define the need for this library[Jerin]
> - Added RTE_EVENT_QUEUE_CFG_*_ONLY configuration parameters in
> struct rte_event_queue_conf to enable optimized sw implementation [Bruce]
> - Introduced RTE_EVENT_OP* ops [Bruce]
> - Added nb_event_queue_flows,nb_event_port_dequeue_depth, nb_event_port_enqueue_depth
> in rte_event_dev_configure() like ethdev and crypto library[Jerin]
> - Removed rte_event_release() and replaced with RTE_EVENT_OP_RELEASE ops to
> reduce fast path APIs and it is redundant too[Jerin]
> - In the view of better application portability, Removed pin_event
> from rte_event_enqueue as it is just hint and Intel/NXP can not support it[Jerin]
> - Added rte_event_port_links_get()[Jerin]
> - Added rte_event_dev_dump[Harry]
>
> Notes:
>
> - This patch set is check-patch clean with an exception that
> 03/06 has one WARNING:MACRO_WITH_FLOW_CONTROL
> - Looking forward to getting additional maintainers for libeventdev
>
> TODO:
> 1) Create user guide
>
> Jerin Jacob (6):
> eventdev: introduce event driven programming model
> eventdev: define southbound driver interface
> eventdev: implement the northbound APIs
> eventdev: implement PMD registration functions
> event/skeleton: add skeleton eventdev driver
> app/test: unit test case for eventdev APIs
>
> MAINTAINERS | 5 +
> app/test/Makefile | 2 +
> app/test/test_eventdev.c | 778 +++++++++++
> config/common_base | 14 +
> doc/api/doxy-api-index.md | 1 +
> doc/api/doxy-api.conf | 1 +
> drivers/Makefile | 1 +
> drivers/event/Makefile | 36 +
> drivers/event/skeleton/Makefile | 55 +
> .../skeleton/rte_pmd_skeleton_event_version.map | 4 +
> drivers/event/skeleton/skeleton_eventdev.c | 518 +++++++
> drivers/event/skeleton/skeleton_eventdev.h | 68 +
> lib/Makefile | 1 +
> lib/librte_eal/common/include/rte_log.h | 1 +
> lib/librte_eventdev/Makefile | 57 +
> lib/librte_eventdev/rte_eventdev.c | 1220 +++++++++++++++++
> lib/librte_eventdev/rte_eventdev.h | 1407 ++++++++++++++++++++
> lib/librte_eventdev/rte_eventdev_pmd.h | 511 +++++++
> lib/librte_eventdev/rte_eventdev_version.map | 39 +
> mk/rte.app.mk | 5 +
> 20 files changed, 4724 insertions(+)
> create mode 100644 app/test/test_eventdev.c
> create mode 100644 drivers/event/Makefile
> create mode 100644 drivers/event/skeleton/Makefile
> create mode 100644 drivers/event/skeleton/rte_pmd_skeleton_event_version.map
> create mode 100644 drivers/event/skeleton/skeleton_eventdev.c
> create mode 100644 drivers/event/skeleton/skeleton_eventdev.h
> create mode 100644 lib/librte_eventdev/Makefile
> create mode 100644 lib/librte_eventdev/rte_eventdev.c
> create mode 100644 lib/librte_eventdev/rte_eventdev.h
> create mode 100644 lib/librte_eventdev/rte_eventdev_pmd.h
> create mode 100644 lib/librte_eventdev/rte_eventdev_version.map
>
On Sun, Dec 18, 2016 at 07:51:29PM +0530, Jerin Jacob wrote:
> As previously discussed in RFC v1 [1], RFC v2 [2], with changes
> described in [3] (also pasted below), here is the first non-draft series
> for this new API.
>
> [1] http://dpdk.org/ml/archives/dev/2016-August/045181.html
> [2] http://dpdk.org/ml/archives/dev/2016-October/048592.html
> [3] http://dpdk.org/ml/archives/dev/2016-October/048196.html
>
> v2..v3:
>
> 1) Changed struct rte_event layout more aligment balanced(Harry, Jerin)
> 2) Changed event_ptr type to void* from uintptr_t(Bruce)
> 3) Changed ev[] as const in rte_event_enqueue_burst to disallow
> drivers from modifying the events passed in(Bruce)
> 4) Removed queue memory allocation from common code as some drivers may not need
> it(Bruce)
> 5) Removed "struct rte_event_queue_link" and replaced with queues and priorities
> in the link and link_get API to avoid one redirection to use the API(Bruce)
>
> v1..v2:
> 1) Remove unnecessary header files from rte_eventdev.h(Thomas)
> 2) Removed PMD driver name(EVENTDEV_NAME_SKELETON_PMD) from rte_eventdev.h(Thomas)
> 3) Removed different #define for different priority schemes. Changed to
> one event device RTE_EVENT_DEV_PRIORITY_* priority (Bruce)
> 4) add const to rte_event_dev_configure(), rte_event_queue_setup(),
> rte_event_port_setup(), rte_event_port_link()(Bruce)
> 5) Fixed missing dev argument in dev->schedule() function(Bruce)
> 6) Changed \see to @see in doxgen comments(Thomas)
> 7) Added additional text in specification to clarify the queue depth(Thomas)
> 8) Changed wait to timeout across the specification(Thomas)
> 9) Added longer explanation for RTE_EVENT_OP_NEW and RTE_EVENT_OP_FORWARD(Thomas)
> 10) Fixed issue with RTE_EVENT_OP_RELEASE doxgen formatting(Thomas)
> 11) Changed to RTE_EVENT_DEV_CFG_FLAG_ from RTE_EVENT_DEV_CFG_(Thomas)
> 12) Changed to EVENT_QUEUE_CFG_FLAG_ from EVENT_QUEUE_CFG_(Thomas)
> 13) s/RTE_EVENT_TYPE_CORE/RTE_EVENT_TYPE_CPU/(Thomas, Gage)
> 14) Removed non burst API and kept only the burst API in the API specification
> (Thomas, Bruce, Harry, Jerin)
> -- Driver interface has non burst API, selection of the non burst API is based
> on num_objects == 1
> 15) sizeeof(struct rte_event) was not 16 in v1. Fixed it in v2
> -- reduced the width of event_type to 4bit to save space for future change
> -- introduced impl_opaque for implementation specific opaque data(Harry),
> Something useful for HW driver too, in the context of removal the need for sepeare
> release API.
> -- squashed other element size and provided enough space to impl_opaque(Jerin)
> -- added RTE_BUILD_BUG_ON(sizeof(struct rte_event) != 16); check
> 16) add union of uint64_t in the second element in struct rte_event to
> make sure the structure has 16byte address all arch(Thomas)
> 17) Fixed invalid check of nb_atomic_order_sequences in implementation(Gage)
> 18) s/EDEV_LOG_ERR/RTE_EDEV_LOG_ERR(Thomas)
> 19) s/rte_eventdev_pmd_/rte_event_pmd_/(Bruce)
> 20) added fine details of distributed vs centralized scheduling information
> in the specification and introduced RTE_EVENT_DEV_CAP_FLAG_DISTRIBUTED_SCHED
> flag(Gage)
> 21)s/RTE_EVENT_QUEUE_CFG_FLAG_SINGLE_CONSUMER/RTE_EVENT_QUEUE_CFG_FLAG_SINGLE_LINK (Jerin)
> to remove the confusion to between another producer and consumer in sw eventdev driver
> 22) Northbound api implementation patch spited to more logical patches(Thomas)
>
> Changes since RFC v2:
>
> - Updated the documentation to define the need for this library[Jerin]
> - Added RTE_EVENT_QUEUE_CFG_*_ONLY configuration parameters in
> struct rte_event_queue_conf to enable optimized sw implementation [Bruce]
> - Introduced RTE_EVENT_OP* ops [Bruce]
> - Added nb_event_queue_flows,nb_event_port_dequeue_depth, nb_event_port_enqueue_depth
> in rte_event_dev_configure() like ethdev and crypto library[Jerin]
> - Removed rte_event_release() and replaced with RTE_EVENT_OP_RELEASE ops to
> reduce fast path APIs and it is redundant too[Jerin]
> - In the view of better application portability, Removed pin_event
> from rte_event_enqueue as it is just hint and Intel/NXP can not support it[Jerin]
> - Added rte_event_port_links_get()[Jerin]
> - Added rte_event_dev_dump[Harry]
>
> Notes:
>
> - This patch set is check-patch clean with an exception that
> 03/06 has one WARNING:MACRO_WITH_FLOW_CONTROL
> - Looking forward to getting additional maintainers for libeventdev
>
> TODO:
> 1) Create user guide
>
> Jerin Jacob (6):
> eventdev: introduce event driven programming model
> eventdev: define southbound driver interface
> eventdev: implement the northbound APIs
> eventdev: implement PMD registration functions
> event/skeleton: add skeleton eventdev driver
> app/test: unit test case for eventdev APIs
>
Hi Jerin,
other than the couple of comments I've made in replies to the individual
patches, this looks pretty good to me. Only additional comment I have is
that some of the macro names are a little long, and maybe we can shorten
them For example, you've added "_FLAG_" into the config flag macros,
and I'm not sure that is necessary. Similarly, I think we can drop
"_DEV_" from the PRIORITY names to shorten them.
Irrespective of these naming suggestions, once the other couple of
comments are taken care of, I think this set is suitable for merging to
the next-event tree.
Series Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Regards,
/Bruce
On Tue, Dec 20, 2016 at 11:13:42AM +0000, Bruce Richardson wrote:
> On Sun, Dec 18, 2016 at 07:51:29PM +0530, Jerin Jacob wrote:
> > As previously discussed in RFC v1 [1], RFC v2 [2], with changes
> > described in [3] (also pasted below), here is the first non-draft series
> > for this new API.
> >
> > [1] http://dpdk.org/ml/archives/dev/2016-August/045181.html
> > [2] http://dpdk.org/ml/archives/dev/2016-October/048592.html
> > [3] http://dpdk.org/ml/archives/dev/2016-October/048196.html
> >
> > v2..v3:
> >
> > - This patch set is check-patch clean with an exception that
> > 03/06 has one WARNING:MACRO_WITH_FLOW_CONTROL
> > - Looking forward to getting additional maintainers for libeventdev
> >
> > TODO:
> > 1) Create user guide
> >
> > Jerin Jacob (6):
> > eventdev: introduce event driven programming model
> > eventdev: define southbound driver interface
> > eventdev: implement the northbound APIs
> > eventdev: implement PMD registration functions
> > event/skeleton: add skeleton eventdev driver
> > app/test: unit test case for eventdev APIs
> >
> Hi Jerin,
Hi Bruce,
>
> other than the couple of comments I've made in replies to the individual
> patches, this looks pretty good to me. Only additional comment I have is
Thanks
> that some of the macro names are a little long, and maybe we can shorten
> them For example, you've added "_FLAG_" into the config flag macros,
> and I'm not sure that is necessary. Similarly, I think we can drop
> "_DEV_" from the PRIORITY names to shorten them.
OK. I will remove the explicit _FLAG_ to shorten macro name.
The _DEV_ in PRIORITY is not that long. So I would like to keep it for
consistency and to denote it across priorities in event dev.
>
> Irrespective of these naming suggestions, once the other couple of
> comments are taken care of, I think this set is suitable for merging to
> the next-event tree.
I will send v4 with fixes and your suggestions. If their is no further
comment on that, we will merge to next-event tree
>
> Series Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>
> Regards,
> /Bruce
>
On Tue, Dec 20, 2016 at 06:39:30PM +0530, Jerin Jacob wrote:
> On Tue, Dec 20, 2016 at 11:13:42AM +0000, Bruce Richardson wrote:
> > On Sun, Dec 18, 2016 at 07:51:29PM +0530, Jerin Jacob wrote:
> > > As previously discussed in RFC v1 [1], RFC v2 [2], with changes
> > > described in [3] (also pasted below), here is the first non-draft series
> > > for this new API.
> > >
> > > [1] http://dpdk.org/ml/archives/dev/2016-August/045181.html
> > > [2] http://dpdk.org/ml/archives/dev/2016-October/048592.html
> > > [3] http://dpdk.org/ml/archives/dev/2016-October/048196.html
> > >
> > > v2..v3:
> > >
> > > - This patch set is check-patch clean with an exception that
> > > 03/06 has one WARNING:MACRO_WITH_FLOW_CONTROL
> > > - Looking forward to getting additional maintainers for libeventdev
> > >
> > > TODO:
> > > 1) Create user guide
> > >
> > > Jerin Jacob (6):
> > > eventdev: introduce event driven programming model
> > > eventdev: define southbound driver interface
> > > eventdev: implement the northbound APIs
> > > eventdev: implement PMD registration functions
> > > event/skeleton: add skeleton eventdev driver
> > > app/test: unit test case for eventdev APIs
> > >
> > Hi Jerin,
>
> Hi Bruce,
>
> >
> > other than the couple of comments I've made in replies to the individual
> > patches, this looks pretty good to me. Only additional comment I have is
>
> Thanks
>
> > that some of the macro names are a little long, and maybe we can shorten
> > them For example, you've added "_FLAG_" into the config flag macros,
> > and I'm not sure that is necessary. Similarly, I think we can drop
> > "_DEV_" from the PRIORITY names to shorten them.
>
> OK. I will remove the explicit _FLAG_ to shorten macro name.
> The _DEV_ in PRIORITY is not that long. So I would like to keep it for
> consistency and to denote it across priorities in event dev.
>
> >
> > Irrespective of these naming suggestions, once the other couple of
> > comments are taken care of, I think this set is suitable for merging to
> > the next-event tree.
>
> I will send v4 with fixes and your suggestions. If their is no further
> comment on that, we will merge to next-event tree
>
I'm not sure a v4 is needed, unless you especially want to do one.
Given the scope of the suggested changes I think you can just make
those changes on apply to the next-event tree.
/Bruce
2016-12-04 02:25, Jerin Jacob:
> v2:
> - No changes in eal: postpone vdev initialization
> - Added new patch "eal: rename dev init API for consistency" as
> suggested by Shreyansh Jain
> http://dpdk.org/dev/patchwork/patch/17096/
Let's forget this rename and apply the v1 instead.
These functions are going to be reworked so the name will change
in other series probably.
2016-11-20 13:30, Jerin Jacob:
> Some platform like octeontx may use pci and
> vdev based combined device to represent a logical
> dpdk functional device.In such case, postponing the
> vdev initialization after pci device
> initialization will provide the better view of
> the pci device resources in the system in
> vdev's probe function, and it allows better
> functional subsystem registration in vdev probe
> function.
>
> As a bonus, This patch fixes a bond device
> initialization use case.
>
> example command to reproduce the issue:
> ./testpmd -c 0x2 --vdev 'eth_bond0,mode=0,
> slave=0000:02:00.0,slave=0000:03:00.0' --
> --port-topology=chained
>
> root cause:
> In existing case(vdev initialization and then pci
> initialization), creates three Ethernet ports with
> following port ids
> 0 - Bond device
> 1 - PCI device 0
> 2 - PCI devive 1
>
> Since testpmd, calls the configure/start on all the ports on
> start up,it will translate to following illegal setup sequence
>
> 1)bond device configure/start
> 1.1) pci device0 stop/configure/start
> 1.2) pci device1 stop/configure/start
> 2)pci device 0 configure(illegal setup case,
> as device in start state)
>
> The fix changes the initialization sequence and
> allow initialization in following valid setup order
> 1) pcie device 0 configure/start
> 2) pcie device 1 configure/start
> 3) bond device 2 configure/start
> 3.1) pcie device 0/stop/configure/start
> 3.2) pcie device 1/stop/configure/start
>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Applied, thanks
On Tue, Dec 20, 2016 at 01:22:51PM +0000, Bruce Richardson wrote:
> On Tue, Dec 20, 2016 at 06:39:30PM +0530, Jerin Jacob wrote:
> > On Tue, Dec 20, 2016 at 11:13:42AM +0000, Bruce Richardson wrote:
> > > On Sun, Dec 18, 2016 at 07:51:29PM +0530, Jerin Jacob wrote:
> > > > As previously discussed in RFC v1 [1], RFC v2 [2], with changes
> > > > described in [3] (also pasted below), here is the first non-draft series
> > > > for this new API.
> > > >
> > > > [1] http://dpdk.org/ml/archives/dev/2016-August/045181.html
> > > > [2] http://dpdk.org/ml/archives/dev/2016-October/048592.html
> > > > [3] http://dpdk.org/ml/archives/dev/2016-October/048196.html
> > > >
> > > > v2..v3:
> > > >
> > > > - This patch set is check-patch clean with an exception that
> > > > 03/06 has one WARNING:MACRO_WITH_FLOW_CONTROL
> > > > - Looking forward to getting additional maintainers for libeventdev
> > > >
> > > > TODO:
> > > > 1) Create user guide
> > > >
> > > > Jerin Jacob (6):
> > > > eventdev: introduce event driven programming model
> > > > eventdev: define southbound driver interface
> > > > eventdev: implement the northbound APIs
> > > > eventdev: implement PMD registration functions
> > > > event/skeleton: add skeleton eventdev driver
> > > > app/test: unit test case for eventdev APIs
> > > >
> > > Hi Jerin,
> >
> > Hi Bruce,
> >
> > >
> > > other than the couple of comments I've made in replies to the individual
> > > patches, this looks pretty good to me. Only additional comment I have is
> >
> > Thanks
> >
> > > that some of the macro names are a little long, and maybe we can shorten
> > > them For example, you've added "_FLAG_" into the config flag macros,
> > > and I'm not sure that is necessary. Similarly, I think we can drop
> > > "_DEV_" from the PRIORITY names to shorten them.
> >
> > OK. I will remove the explicit _FLAG_ to shorten macro name.
> > The _DEV_ in PRIORITY is not that long. So I would like to keep it for
> > consistency and to denote it across priorities in event dev.
> >
> > >
> > > Irrespective of these naming suggestions, once the other couple of
> > > comments are taken care of, I think this set is suitable for merging to
> > > the next-event tree.
> >
> > I will send v4 with fixes and your suggestions. If their is no further
> > comment on that, we will merge to next-event tree
> >
> I'm not sure a v4 is needed, unless you especially want to do one.
> Given the scope of the suggested changes I think you can just make
> those changes on apply to the next-event tree.
Applied to dpdk-next-eventdev tree.
Thanks
>
> /Bruce
@@ -577,9 +577,6 @@ rte_eal_init(int argc, char **argv)
rte_config.master_lcore, thread_id, cpuset,
ret == 0 ? "" : "...");
- if (rte_eal_dev_init() < 0)
- rte_panic("Cannot init pmd devices\n");
-
RTE_LCORE_FOREACH_SLAVE(i) {
/*
@@ -616,6 +613,9 @@ rte_eal_init(int argc, char **argv)
if (rte_eal_pci_probe())
rte_panic("Cannot probe PCI\n");
+ if (rte_eal_dev_init() < 0)
+ rte_panic("Cannot init pmd devices\n");
+
rte_eal_mcfg_complete();
return fctret;
@@ -841,9 +841,6 @@ rte_eal_init(int argc, char **argv)
rte_config.master_lcore, (int)thread_id, cpuset,
ret == 0 ? "" : "...");
- if (rte_eal_dev_init() < 0)
- rte_panic("Cannot init pmd devices\n");
-
if (rte_eal_intr_init() < 0)
rte_panic("Cannot init interrupt-handling thread\n");
@@ -887,6 +884,9 @@ rte_eal_init(int argc, char **argv)
if (rte_eal_pci_probe())
rte_panic("Cannot probe PCI\n");
+ if (rte_eal_dev_init() < 0)
+ rte_panic("Cannot init pmd devices\n");
+
rte_eal_mcfg_complete();
return fctret;