Re: [ovs-dev] [PATCH v2 2/3] netdev-dpdk: Convert initialization from cmdline to db
Aaron Conole writes:
> "Traynor, Kevin" writes:
>>> -Original Message-
>>> From: Aaron Conole [mailto:acon...@redhat.com]
>>> Sent: Monday, January 4, 2016 9:47 PM
>>> To: dev@openvswitch.org; Flavio Leitner; Traynor, Kevin
>>> Subject: [PATCH v2 2/3] netdev-dpdk: Convert initialization from cmdline to
>>> db
>>>
>>> Existing DPDK integration is provided by use of command line options which
>>> must be split out and passed to librte in a special manner. However, this
>>> forces any configuration to be passed by way of a special DPDK flag, and
>>> interferes with ovs+dpdk packaging solutions.
>>>
>>> This commit delays dpdk initialization until the first DPDK netdev is added
>>> to the bridge, at which point ovs initializes librte. It pulls all of
>>> the config data from the OVS database, and assembles a new argv/argc
>>> pair to be passed along.
>>>
>>> Signed-off-by: Aaron Conole
>>> ---
>>> v2:
>>> * Removed trailing whitespace
>>> * Followed for() loop brace coding style
>>> * Automatically enable DPDK when adding a DPDK enabled port
>>> * Fixed an issue on startup when DPDK enabled ports are present
>>> * Updated the documentation (including vswitch.xml) and documented all
>>> new parameters
>>> * Dropped the premature initialization test
>>
>> Hi, mostly very minor comments below,
<>
>>>
>>> -static inline int
>>> -dpdk_init(int argc, char **argv)
>>> +static inline void
>>> +dpdk_config(const struct ovsrec_open_vswitch *ovs_cfg)
>>> {
>>> -if (argc >= 2 && !strcmp(argv[1], "--dpdk")) {
>>> -ovs_fatal(0, "DPDK support not built into this copy of Open
>>> vSwitch.");
>>> +static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;
>>> +
>>> +if (ovs_cfg && ovsthread_once_start(&once)) {
>>> +if(smap_get_bool(&ovs_cfg->other_config, "dpdk", false)) {
>>> +ovs_fatal(0, "DPDK not supported in this copy of Open
>>> vSwitch.");
>>
>> "dpdk" db entry is not in this version of the patchset.
>
> Good catch... I should have tested it more thoroughly.
>
>> Might be best for this function to just do nothing now. A print doesn't
>> even seem to make sense as this will be called for OVS without DPDK.
>
> Okay.
>
I'm rethinking. We need the print in this case: user has dpdk-init=true
in the database, but this version of OVS doesn't support DPDK. The
netdevs in the database will be broken, and the user will be unaware of
why.
It's the same as the original behavior - if someone requests dpdk at
runtime, but the support wasn't there at compile time, we should abort
altogether and let the user clean things up. So that's what I'm
including in my patchset.
-Aaron
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2 2/3] netdev-dpdk: Convert initialization from cmdline to db
> -Original Message- > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Aaron Conole > Sent: Monday, January 11, 2016 6:51 PM > To: Zoltan Kiss > Cc: dev@openvswitch.org; Flavio Leitner > Subject: Re: [ovs-dev] [PATCH v2 2/3] netdev-dpdk: Convert initialization > from cmdline to db > > Zoltan Kiss writes: > > On 08/01/16 16:31, Aaron Conole wrote: > >> Panu Matilainen writes: > >>> On 01/04/2016 11:46 PM, Aaron Conole wrote: > >>>> Existing DPDK integration is provided by use of command line options > which > >>>> must be split out and passed to librte in a special manner. However, > this > >>>> forces any configuration to be passed by way of a special DPDK flag, and > >>>> interferes with ovs+dpdk packaging solutions. > >>>> > >>>> This commit delays dpdk initialization until the first DPDK netdev is > added > >>>> to the bridge, at which point ovs initializes librte. > >>> > >>> On thing to keep in mind is that rte_eal_init() can and will tear down > >>> the entire process on failure since DPDK calls rte_panic() if > >>> something so much as sneezes. In current OVS this occurs on service > >>> startup where its relatively harmless, but with lazy initialization > >>> there could be already be other activity that is in risk of getting > >>> terminated when the first DPDK port is added. > >>> > >>> Fixing rte_eal_init() to gracefully return on failure has been > >>> discussed, and agreed on in principle, on DPDK list but all current > >>> DPDK versions are nasty wrt that. > >>> > >>> - Panu - > >> > >> So, I've waffled back and forth on this. I understand the reason to be > >> nervous about an always init option (because that wastes lots of > >> resources when the system won't ever use dpdk). I also understand the > >> possible issues *today* with dpdk_init, but even then, it's a dpdk issue > >> which we want fixed anyway, so I don't know that this should hold up > >> this patch. > > > > I couldn't find the original email where this discussion happened: why > > is it required to be able to init DPDK on the fly? I mean it's a nice > > bit, but brings in a lot of trouble. On the other hand, asking the > > user to set a "other_config:odp=true" and then restart ovs-vswitchd is > > not a huge thing to ask. > > You won't find such a discussion - it's never been "required," as > such. It is very desirable, as having such automatic behavior reduces the > amount of steps required to get up and running with DPDK enabled > OVS. This is, imho, the argument of both Panu and Kevin when they think > a big on/off switch is less than elegant. I tend to agree with that, as well. > > If the user is going through the trouble of compiling with DPDK support, and > then wants to add a DPDK port, having to also set > "other_config:dpdk=yes" seems like too many ok dialogs. I hope the > analogy makes sense. > > That said, it's really an unneeded enhancement, and I've pitched the > idea to folks at the office within my elastic-shooting range. The answer > has been consistently "This is an enhancement, not a requirement." So > I'll drop the lazy-init feature for now. > > >> It's definitely a more elegant solution to do the lazy init, but I think > >> there could be times where we want a "stop everything" button for > >> occasions where testing without DPDK doing it's thing are desired. > >> > >> However, I think I've come up with a solution that gives us flexibility > >> to support these cases without much additional work, so let me know what > >> you think: > >> > >> First, go back to the dpdk true/false flag > >> Second, add a patch in the series which changes true/false to a tristate > >> on/off/lazy allowing the policy of when to initialize DPDK to be user > >> defined. We can default it to 'off' or 'lazy', but it can be changed to > >> 'on' if we want. > >> > >> What do folks think? Too much work and code for not enough gains? > > As I wrote above, the 'second' part of this is a great follow up > enhancement, but for now I'm going to go back to the giant flag, and we > can take it as 'future development'. I think we all agree that removing the vswitchd dpdk mandatory cmdline args by putting them in the db/code with defaults is good for usability and getting that alone enabled through this patch would be a good outcome IMHO. I see "other_config:dpdk=yes" and lazy init's as ways to enable a common build. That's good for usability and support but I think it's a separate enough change to warrant a separate patchset/discussion. > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2 2/3] netdev-dpdk: Convert initialization from cmdline to db
"Traynor, Kevin" writes: >> -Original Message- >> From: Aaron Conole [mailto:acon...@redhat.com] >> Sent: Monday, January 4, 2016 9:47 PM >> To: dev@openvswitch.org; Flavio Leitner; Traynor, Kevin >> Subject: [PATCH v2 2/3] netdev-dpdk: Convert initialization from cmdline to >> db >> >> Existing DPDK integration is provided by use of command line options which >> must be split out and passed to librte in a special manner. However, this >> forces any configuration to be passed by way of a special DPDK flag, and >> interferes with ovs+dpdk packaging solutions. >> >> This commit delays dpdk initialization until the first DPDK netdev is added >> to the bridge, at which point ovs initializes librte. It pulls all of >> the config data from the OVS database, and assembles a new argv/argc >> pair to be passed along. >> >> Signed-off-by: Aaron Conole >> --- >> v2: >> * Removed trailing whitespace >> * Followed for() loop brace coding style >> * Automatically enable DPDK when adding a DPDK enabled port >> * Fixed an issue on startup when DPDK enabled ports are present >> * Updated the documentation (including vswitch.xml) and documented all >> new parameters >> * Dropped the premature initialization test > > Hi, mostly very minor comments below, Kevin, thanks for the review! > >> >> INSTALL.DPDK.md | 75 >> lib/netdev-dpdk.c | 224 +++--- >> -- >> lib/netdev-dpdk.h | 19 ++-- >> vswitchd/bridge.c | 3 + >> vswitchd/ovs-vswitchd.c | 25 +- >> vswitchd/vswitch.xml| 102 +- >> 6 files changed, 341 insertions(+), 107 deletions(-) >> >> diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md >> index 96b686c..2dd2120 100644 >> --- a/INSTALL.DPDK.md >> +++ b/INSTALL.DPDK.md >> @@ -143,22 +143,59 @@ Using the DPDK with ovs-vswitchd: >> >> 5. Start vswitchd: >> >> - DPDK configuration arguments can be passed to vswitchd via `--dpdk` >> - argument. This needs to be first argument passed to vswitchd process. >> - dpdk arg -c is ignored by ovs-dpdk, but it is a required parameter >> - for dpdk initialization. >> + DPDK configuration arguments can be passed to vswitchd via Open_vSwitch >> + other_config database. The recognized configuration options are listed. > > 'Defaults will be provided for all values not set.' Thanks, will add this. > >> + >> + * dpdk-lcore-mask >> + Specifies the CPU cores on which dpdk lcore threads should be spawned. >> + The DPDK lcore threads are used for DPDK library tasks, such as >> + library internal message processing, logging, etc. Value should be in >> + the form of a hex string (so '0x123') similar to the 'taskset' mask >> + input. > > 'CPU cores' and '0x123' imply it will be multiple cores in this case - better > to change to CPU core and 0x1 > > Also, I don't think the 0x prefix is accepted based on using pmd-cpu-mask. Hrrm.. okay. I used the documentation on pmd-cpu-mask as my guideline, so if that's broken it's a bug against pmd-cpu-mask as well (it's documented as a ). >> + If not specified, the value will be determined by choosing the lowest >> + CPU core from initial cpu affinity list. Otherwise, the value will be >> + passed directly to the DPDK library. >> + For performance reasons, it is best to set this to a single core on >> + the system, rather than allow lcore threads to float. > > I suppose it depends on the system load and vswitch usage as to which will > give > better performance but I agree setting a dedicated core is at least more > deterministic and less risky, so statement is probably fine. Well, I used the advice in rings as my guideline here. I think it's correct to say that the workload is important. Okay, I'll think if there's a better comment to use here. >> + >> + * dpdk-mem-channels >> + This sets the number of memory spread channels per CPU socket. It is >> purely >> + an optimization flag. >> + >> + * dpdk-alloc-mem >> + This sets the total memory to preallocate from hugepages regardless of >> + processor socket. It is recommended to use dpdk-socket-mem instead. >> + >> + * dpdk-socket-mem >> + Comma separated list of memory to pre-allocate from hugepages on specific >> + sockets. >> + >> + * dpdk-hugepage-dir >> + Directory where hugetlbfs is mounted >> + >> + * cuse-dev-name >> + Option to set the vhost_cuse character device name. >> + >> + * vhost-sock-dir >> + Option to set the path to the vhost_user unix socket files. >> + >> + NOTE: Changing any of these options requires restarting the ovs-vswitchd >> + application. >> + >> + Open vSwitch can be started as normal. DPDK will not be initialized until >> + the first DPDK-enabled port is added to the bridge. >> >> ``` >> export DB_SOCK=/usr/local/var/run/openvswitch/db.sock >> - ovs-vswitchd --dpdk -c 0x1 -n 4 -- unix:$DB_SOCK --pidfile --detach >> + ovs-vswitchd unix:$DB_SOCK --pidfile --detac
Re: [ovs-dev] [PATCH v2 2/3] netdev-dpdk: Convert initialization from cmdline to db
> -Original Message- > From: Aaron Conole [mailto:acon...@redhat.com] > Sent: Monday, January 4, 2016 9:47 PM > To: dev@openvswitch.org; Flavio Leitner; Traynor, Kevin > Subject: [PATCH v2 2/3] netdev-dpdk: Convert initialization from cmdline to > db > > Existing DPDK integration is provided by use of command line options which > must be split out and passed to librte in a special manner. However, this > forces any configuration to be passed by way of a special DPDK flag, and > interferes with ovs+dpdk packaging solutions. > > This commit delays dpdk initialization until the first DPDK netdev is added > to the bridge, at which point ovs initializes librte. It pulls all of > the config data from the OVS database, and assembles a new argv/argc > pair to be passed along. > > Signed-off-by: Aaron Conole > --- > v2: > * Removed trailing whitespace > * Followed for() loop brace coding style > * Automatically enable DPDK when adding a DPDK enabled port > * Fixed an issue on startup when DPDK enabled ports are present > * Updated the documentation (including vswitch.xml) and documented all > new parameters > * Dropped the premature initialization test Hi, mostly very minor comments below, > > INSTALL.DPDK.md | 75 > lib/netdev-dpdk.c | 224 +++--- > -- > lib/netdev-dpdk.h | 19 ++-- > vswitchd/bridge.c | 3 + > vswitchd/ovs-vswitchd.c | 25 +- > vswitchd/vswitch.xml| 102 +- > 6 files changed, 341 insertions(+), 107 deletions(-) > > diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md > index 96b686c..2dd2120 100644 > --- a/INSTALL.DPDK.md > +++ b/INSTALL.DPDK.md > @@ -143,22 +143,59 @@ Using the DPDK with ovs-vswitchd: > > 5. Start vswitchd: > > - DPDK configuration arguments can be passed to vswitchd via `--dpdk` > - argument. This needs to be first argument passed to vswitchd process. > - dpdk arg -c is ignored by ovs-dpdk, but it is a required parameter > - for dpdk initialization. > + DPDK configuration arguments can be passed to vswitchd via Open_vSwitch > + other_config database. The recognized configuration options are listed. 'Defaults will be provided for all values not set.' > + > + * dpdk-lcore-mask > + Specifies the CPU cores on which dpdk lcore threads should be spawned. > + The DPDK lcore threads are used for DPDK library tasks, such as > + library internal message processing, logging, etc. Value should be in > + the form of a hex string (so '0x123') similar to the 'taskset' mask > + input. 'CPU cores' and '0x123' imply it will be multiple cores in this case - better to change to CPU core and 0x1 Also, I don't think the 0x prefix is accepted based on using pmd-cpu-mask. > + If not specified, the value will be determined by choosing the lowest > + CPU core from initial cpu affinity list. Otherwise, the value will be > + passed directly to the DPDK library. > + For performance reasons, it is best to set this to a single core on > + the system, rather than allow lcore threads to float. I suppose it depends on the system load and vswitch usage as to which will give better performance but I agree setting a dedicated core is at least more deterministic and less risky, so statement is probably fine. > + > + * dpdk-mem-channels > + This sets the number of memory spread channels per CPU socket. It is > purely > + an optimization flag. > + > + * dpdk-alloc-mem > + This sets the total memory to preallocate from hugepages regardless of > + processor socket. It is recommended to use dpdk-socket-mem instead. > + > + * dpdk-socket-mem > + Comma separated list of memory to pre-allocate from hugepages on specific > + sockets. > + > + * dpdk-hugepage-dir > + Directory where hugetlbfs is mounted > + > + * cuse-dev-name > + Option to set the vhost_cuse character device name. > + > + * vhost-sock-dir > + Option to set the path to the vhost_user unix socket files. > + > + NOTE: Changing any of these options requires restarting the ovs-vswitchd > + application. > + > + Open vSwitch can be started as normal. DPDK will not be initialized until > + the first DPDK-enabled port is added to the bridge. > > ``` > export DB_SOCK=/usr/local/var/run/openvswitch/db.sock > - ovs-vswitchd --dpdk -c 0x1 -n 4 -- unix:$DB_SOCK --pidfile --detach > + ovs-vswitchd unix:$DB_SOCK --pidfile --detach > ``` > > If allocated more than one GB hugepage (as for IVSHMEM), set amount and > use NUMA node 0 memory: > > ``` > - ovs-vswitchd --dpdk -c 0x1 -n 4 --socket-mem 1024,0 \ > - -- unix:$DB_SOCK --pidfile --detach > + ovs-vsctl --no-wait set Open_vSwitch . > other_config:dpdk_socket_mem="1024,0" > + ovs-vswitchd unix:$DB_SOCK --pidfile --detach > ``` > > 6. Add bridge & ports > @@ -521,11 +558,12 @@ have arbitrary names. > `/usr/local/var/run/openvswitch/vhost-user-1`, which you must provide
Re: [ovs-dev] [PATCH v2 2/3] netdev-dpdk: Convert initialization from cmdline to db
Zoltan Kiss writes: > On 08/01/16 16:31, Aaron Conole wrote: >> Panu Matilainen writes: >>> On 01/04/2016 11:46 PM, Aaron Conole wrote: Existing DPDK integration is provided by use of command line options which must be split out and passed to librte in a special manner. However, this forces any configuration to be passed by way of a special DPDK flag, and interferes with ovs+dpdk packaging solutions. This commit delays dpdk initialization until the first DPDK netdev is added to the bridge, at which point ovs initializes librte. >>> >>> On thing to keep in mind is that rte_eal_init() can and will tear down >>> the entire process on failure since DPDK calls rte_panic() if >>> something so much as sneezes. In current OVS this occurs on service >>> startup where its relatively harmless, but with lazy initialization >>> there could be already be other activity that is in risk of getting >>> terminated when the first DPDK port is added. >>> >>> Fixing rte_eal_init() to gracefully return on failure has been >>> discussed, and agreed on in principle, on DPDK list but all current >>> DPDK versions are nasty wrt that. >>> >>> - Panu - >> >> So, I've waffled back and forth on this. I understand the reason to be >> nervous about an always init option (because that wastes lots of >> resources when the system won't ever use dpdk). I also understand the >> possible issues *today* with dpdk_init, but even then, it's a dpdk issue >> which we want fixed anyway, so I don't know that this should hold up >> this patch. > > I couldn't find the original email where this discussion happened: why > is it required to be able to init DPDK on the fly? I mean it's a nice > bit, but brings in a lot of trouble. On the other hand, asking the > user to set a "other_config:odp=true" and then restart ovs-vswitchd is > not a huge thing to ask. You won't find such a discussion - it's never been "required," as such. It is very desirable, as having such automatic behavior reduces the amount of steps required to get up and running with DPDK enabled OVS. This is, imho, the argument of both Panu and Kevin when they think a big on/off switch is less than elegant. I tend to agree with that, as well. If the user is going through the trouble of compiling with DPDK support, and then wants to add a DPDK port, having to also set "other_config:dpdk=yes" seems like too many ok dialogs. I hope the analogy makes sense. That said, it's really an unneeded enhancement, and I've pitched the idea to folks at the office within my elastic-shooting range. The answer has been consistently "This is an enhancement, not a requirement." So I'll drop the lazy-init feature for now. >> It's definitely a more elegant solution to do the lazy init, but I think >> there could be times where we want a "stop everything" button for >> occasions where testing without DPDK doing it's thing are desired. >> >> However, I think I've come up with a solution that gives us flexibility >> to support these cases without much additional work, so let me know what >> you think: >> >> First, go back to the dpdk true/false flag >> Second, add a patch in the series which changes true/false to a tristate >> on/off/lazy allowing the policy of when to initialize DPDK to be user >> defined. We can default it to 'off' or 'lazy', but it can be changed to >> 'on' if we want. >> >> What do folks think? Too much work and code for not enough gains? As I wrote above, the 'second' part of this is a great follow up enhancement, but for now I'm going to go back to the giant flag, and we can take it as 'future development'. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2 2/3] netdev-dpdk: Convert initialization from cmdline to db
On 08/01/16 16:31, Aaron Conole wrote: Panu Matilainen writes: On 01/04/2016 11:46 PM, Aaron Conole wrote: Existing DPDK integration is provided by use of command line options which must be split out and passed to librte in a special manner. However, this forces any configuration to be passed by way of a special DPDK flag, and interferes with ovs+dpdk packaging solutions. This commit delays dpdk initialization until the first DPDK netdev is added to the bridge, at which point ovs initializes librte. On thing to keep in mind is that rte_eal_init() can and will tear down the entire process on failure since DPDK calls rte_panic() if something so much as sneezes. In current OVS this occurs on service startup where its relatively harmless, but with lazy initialization there could be already be other activity that is in risk of getting terminated when the first DPDK port is added. Fixing rte_eal_init() to gracefully return on failure has been discussed, and agreed on in principle, on DPDK list but all current DPDK versions are nasty wrt that. - Panu - So, I've waffled back and forth on this. I understand the reason to be nervous about an always init option (because that wastes lots of resources when the system won't ever use dpdk). I also understand the possible issues *today* with dpdk_init, but even then, it's a dpdk issue which we want fixed anyway, so I don't know that this should hold up this patch. I couldn't find the original email where this discussion happened: why is it required to be able to init DPDK on the fly? I mean it's a nice bit, but brings in a lot of trouble. On the other hand, asking the user to set a "other_config:odp=true" and then restart ovs-vswitchd is not a huge thing to ask. It's definitely a more elegant solution to do the lazy init, but I think there could be times where we want a "stop everything" button for occasions where testing without DPDK doing it's thing are desired. However, I think I've come up with a solution that gives us flexibility to support these cases without much additional work, so let me know what you think: First, go back to the dpdk true/false flag Second, add a patch in the series which changes true/false to a tristate on/off/lazy allowing the policy of when to initialize DPDK to be user defined. We can default it to 'off' or 'lazy', but it can be changed to 'on' if we want. What do folks think? Too much work and code for not enough gains? Thanks, Aaron PS: Thanks for looking at this, Panu! ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2 2/3] netdev-dpdk: Convert initialization from cmdline to db
Panu Matilainen writes: > On 01/04/2016 11:46 PM, Aaron Conole wrote: >> Existing DPDK integration is provided by use of command line options which >> must be split out and passed to librte in a special manner. However, this >> forces any configuration to be passed by way of a special DPDK flag, and >> interferes with ovs+dpdk packaging solutions. >> >> This commit delays dpdk initialization until the first DPDK netdev is added >> to the bridge, at which point ovs initializes librte. > > On thing to keep in mind is that rte_eal_init() can and will tear down > the entire process on failure since DPDK calls rte_panic() if > something so much as sneezes. In current OVS this occurs on service > startup where its relatively harmless, but with lazy initialization > there could be already be other activity that is in risk of getting > terminated when the first DPDK port is added. > > Fixing rte_eal_init() to gracefully return on failure has been > discussed, and agreed on in principle, on DPDK list but all current > DPDK versions are nasty wrt that. > > - Panu - So, I've waffled back and forth on this. I understand the reason to be nervous about an always init option (because that wastes lots of resources when the system won't ever use dpdk). I also understand the possible issues *today* with dpdk_init, but even then, it's a dpdk issue which we want fixed anyway, so I don't know that this should hold up this patch. It's definitely a more elegant solution to do the lazy init, but I think there could be times where we want a "stop everything" button for occasions where testing without DPDK doing it's thing are desired. However, I think I've come up with a solution that gives us flexibility to support these cases without much additional work, so let me know what you think: First, go back to the dpdk true/false flag Second, add a patch in the series which changes true/false to a tristate on/off/lazy allowing the policy of when to initialize DPDK to be user defined. We can default it to 'off' or 'lazy', but it can be changed to 'on' if we want. What do folks think? Too much work and code for not enough gains? Thanks, Aaron PS: Thanks for looking at this, Panu! ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2 2/3] netdev-dpdk: Convert initialization from cmdline to db
On 01/04/2016 11:46 PM, Aaron Conole wrote: Existing DPDK integration is provided by use of command line options which must be split out and passed to librte in a special manner. However, this forces any configuration to be passed by way of a special DPDK flag, and interferes with ovs+dpdk packaging solutions. This commit delays dpdk initialization until the first DPDK netdev is added to the bridge, at which point ovs initializes librte. On thing to keep in mind is that rte_eal_init() can and will tear down the entire process on failure since DPDK calls rte_panic() if something so much as sneezes. In current OVS this occurs on service startup where its relatively harmless, but with lazy initialization there could be already be other activity that is in risk of getting terminated when the first DPDK port is added. Fixing rte_eal_init() to gracefully return on failure has been discussed, and agreed on in principle, on DPDK list but all current DPDK versions are nasty wrt that. - Panu - ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
