[dpdk-dev] One pkt in mbuf chain - virtio pmd driver
Hi, First of all thank you for quick answer! Do we know when exactly this feature will be available? Best Regards, Tomasz Czaus -Original Message- From: Xie, Huawei Sent: Thursday, August 07, 2014 9:07 AM To: Czaus, Tomasz; dev at dpdk.org Cc: Long, Thomas Subject: RE: [dpdk-dev] One pkt in mbuf chain - virtio pmd driver Hi Tomasz: This is a known issue in user space vhost. Will be fixed in subsequent patch once the vhost lib is applied. BR. -Huawei > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Czaus, Tomasz > Sent: Thursday, August 07, 2014 2:20 PM > To: dev at dpdk.org > Subject: [dpdk-dev] One pkt in mbuf chain - virtio pmd driver > > Hello, > > Does virtio pmd driver support scenario when a frame fits in mbuf > chain, this means all headers (eth/ipv4/tcp) are located in first mbuf > and user data is located in next mbuf. I have asked the same question > on dpdk-ovs mailing group, here is a thread and more details: > > https://lists.01.org/pipermail/dpdk-ovs/2014-August/001557.html > > Best Regards, > Tomasz Czaus > > > > Intel Technology Poland sp. z o.o. > ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII > Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP > 957-07- > 52-316 | Kapital zakladowy 200.000 PLN. > > Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego > adresata i moze zawierac informacje poufne. W razie przypadkowego > otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale > jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest > zabronione. > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). If you are not the intended > recipient, please contact the sender and delete all copies; any review > or distribution by others is strictly prohibited. Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
[dpdk-dev] [PATCH 1/2] lib/librte_vhost: vhost library support to facilitate integration with vswitch.
> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Friday, August 08, 2014 1:59 AM
> To: Xie, Huawei
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] lib/librte_vhost: vhost library support to
> facilitate integration with vswitch.
>
> On Fri, 18 Jul 2014 13:39:05 +0800
> Huawei Xie wrote:
>
> > Signed-off-by: Huawei Xie
> > Acked-by: Konstantin Ananyev
> > Acked-by: Thomos Long
>
> This looks good, but there are some style convention issues:
>
> 1. Please don't use really long lines. About 100 or 120 characters is maximum
>reasonable length in an editor
>
I plan to fix the length issues in subsequent patch. There are plenty of them,
which are inherited from old vhost code.
> 2. Don't put space here in function decl.
>
> ERROR: space prohibited after that '*' (ctx:BxW)
> #1183: FILE: lib/librte_vhost/vhost-net-cdev.h:102:
> + int (* set_vring_kick)(struct vhost_device_ctx, struct vhost_vring_file
> *);
>^
>
In this patch, I only run checkpatch.pl against the source file I modified
rather than the patch itself, so missed these checking. I had sent the V3
patch in which those kind of issues are fixed. Please refer to the latest V3
patch.
> 3. Use BSD and kernel style brace
> Not:
>
> +void
> +put_files_struct (struct files_struct *files)
> +{
> + if (atomic_dec_and_test (&files->count))
> + {
> + BUG ();
> + }
> +}
>
> Instead:
> +void
> +put_files_struct (struct files_struct *files)
> +{
> + if (atomic_dec_and_test (&files->count)) {
> + BUG ();
> + }
> +}
>
> 4. All functions that are not used in other files should be marked static.
>For example put_files_struct
>
> 5. Switch should be indented at same level as case:
> Not:
> + switch (ioctl)
> + {
> + case EVENTFD_COPY:
> + if (copy_from_user (&eventfd_copy, argp, sizeof (struct
> eventfd_copy)))
> + return -EFAULT;
> +
>
> Instead:
> + switch (ioctl) {
> + case EVENTFD_COPY:
> + if (copy_from_user (&eventfd_copy, argp, sizeof (struct
> eventfd_copy)))
> + return -EFAULT
Thanks. As stated above, have fixed all the style issues except 80 length
warning in v3 patch.
[dpdk-dev] Is VFIO driver's performance better than IGB_UIO?
I have test the VFIO driver and IGB_UIO driver by l2fwd for many times. I find that the VFIO driver?s performance is not better than the IGB_UIO. Is something wrong with my test? My test is as follow: 1. bind two 82599 ether to VFIO ./tools/dpdk_nic_bind.py -b vfio-pci 03:00.0 03:00.1 2. run the l2fwd to watch the stats info. 3. Bind the 82599 ehter to IGB_UIO ./tools/dpdk_nic_bind.py -b igb_uio 03:00.0 03:00.1 4. run the l2fwd to watch the stats info. The result of test is :?Mpps? VFIO-64-PHY-PHY IGBUIO-64-PHY-PHY VFIO-512-PHY-PHY IGBUIO-512-PHY-PHY 2.6235456 2.3467793 1.9432854 1.9432753 2.5724822 2.5405128 1.9432777 1.9432832 2.2418318 2.5154781 1.9395376 1.9432291 2.470847 2.551112 1.9432767 1.9432756 2.5092176 2.4965851 1.9432705 1.9432733 2.51572 2.4703292 1.9432637 1.9432669 2.6293656 2.472452 1.9432719 1.943283 2.480364 2.6295004 1.9432775 1.943286 2.4242182 2.613162 1.943268 1.9432663 I have two questions: 1. If the result is wrong how can I test the VFIO and IGB_UIO 2. If the result is normal why use VFIO?
[dpdk-dev] Is VFIO driver's performance better than IGB_UIO?
On 08/08/2014 09:41, Linhaifeng wrote: > I have test the VFIO driver and IGB_UIO driver by l2fwd for many times. I > find that the VFIO driver?s performance is not better than the IGB_UIO. You are right, under some conditions UIO is faster, VFIO provides safety. The best solution is a PMD without UIO, neither VFIO. which CPU are you using? Best regards, Vincent
[dpdk-dev] 答复: Is VFIO driver's performance better than IGB_UIO?
Thank you very much. My cpu is "Intel(R) Xeon(R) CPU E5620 @ 2.40GHz" -- ???: Vincent JARDIN [mailto:vincent.jardin at 6wind.com] : 2014?8?8? 15:46 ???: Linhaifeng ??: dev at dpdk.org; lixiao (H); Guofeng (E) ??: Re: [dpdk-dev] Is VFIO driver's performance better than IGB_UIO? On 08/08/2014 09:41, Linhaifeng wrote: > I have test the VFIO driver and IGB_UIO driver by l2fwd for many times. I > find that the VFIO driver?s performance is not better than the IGB_UIO. You are right, under some conditions UIO is faster, VFIO provides safety. The best solution is a PMD without UIO, neither VFIO. which CPU are you using? Best regards, Vincent
[dpdk-dev] Is VFIO driver's performance better than IGB_UIO?
> My cpu is "Intel(R) Xeon(R) CPU E5620 @ 2.40GHz" It is a Westmere if I am correct. So,use UIO.
[dpdk-dev] [PATCHv2] librte_acl make it build/work for 'default' target
> From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Thursday, August 07, 2014 9:12 PM > To: Ananyev, Konstantin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCHv2] librte_acl make it build/work for 'default' > target > > On Thu, Aug 07, 2014 at 07:31:03PM +0100, Konstantin Ananyev wrote: > > Make ACL library to build/work on 'default' architecture: > > - make rte_acl_classify_scalar really scalar > > (make sure it wouldn't use sse4 instrincts through resolve_priority()). > > - Provide two versions of rte_acl_classify code path: > > rte_acl_classify_sse() - could be build and used only on systems with > > sse4.2 > > and upper, return -ENOTSUP on lower arch. > > rte_acl_classify_scalar() - a slower version, but could be build and used > > on all systems. > > - keep common code shared between these two codepaths. > > > > v2 chages: > > run-time selection of most appropriate code-path for given ISA. > > By default the highest supprted one is selected. > > User can still override that selection by manually assigning new value to > > the global function pointer rte_acl_default_classify. > > rte_acl_classify() becomes a macro calling whatever > > rte_acl_default_classify > > points to. > > > > > > Signed-off-by: Konstantin Ananyev > > This is alot better thank you. A few remaining issues. My comments inline too. Thanks Konstantin > > > --- > > app/test-acl/main.c| 13 +- > > lib/librte_acl/Makefile| 5 +- > > lib/librte_acl/acl_bld.c | 5 +- > > lib/librte_acl/acl_match_check.def | 92 > > lib/librte_acl/acl_run.c | 944 > > - > > lib/librte_acl/acl_run.h | 220 + > > lib/librte_acl/acl_run_scalar.c| 197 > > lib/librte_acl/acl_run_sse.c | 630 + > > lib/librte_acl/rte_acl.c | 15 + > > lib/librte_acl/rte_acl.h | 24 +- > > 10 files changed, 1189 insertions(+), 956 deletions(-) > > create mode 100644 lib/librte_acl/acl_match_check.def > > delete mode 100644 lib/librte_acl/acl_run.c > > create mode 100644 lib/librte_acl/acl_run.h > > create mode 100644 lib/librte_acl/acl_run_scalar.c > > create mode 100644 lib/librte_acl/acl_run_sse.c > > > > diff --git a/app/test-acl/main.c b/app/test-acl/main.c > > index d654409..45c6fa6 100644 > > --- a/app/test-acl/main.c > > +++ b/app/test-acl/main.c > > @@ -787,6 +787,10 @@ acx_init(void) > > /* perform build. */ > > ret = rte_acl_build(config.acx, &cfg); > > > > + /* setup default rte_acl_classify */ > > + if (config.scalar) > > + rte_acl_default_classify = rte_acl_classify_scalar; > > + > Exporting this variable as part of the ABI is a bad idea. If the prototype of > the function changes you have to update all your applications. If the prototype of rte_acl_classify will change, most likely you'll have to update code that uses it anyway. > Make the pointer > an internal symbol and set it using a get/set routine with an enum to > represent > the path to choose. That will help isolate the ABI from the internal > implementation. That's was my first intention too. But then I realised that if we'll make it internal, then we'll need to make rte_acl_classify() a proper function and it will cost us extra call (or jump). Also I think user should have an ability to change default classify code path without modifying/rebuilding acl library. For example: a bug in an optimised code path is discovered, or user may want to implement and use his own version of classify(). > It will also let you prevent things like selecting a run time > path that is incompatible with the running system If the user going to update rte_acl_default_classify he is probably smart enough to know what he is doing. >From other hand - user can hit same problem by simply calling >rte_acl_classify_sse() directly. > and prevent path switching > during searches, which may produce unexpected results. Not that I am advertising it, but it should be safe to update rte_acl_default_classify during searches: All versions of classify should produce exactly the same result for each input packet and treat acl context as read-only. > > > > > diff --git a/lib/librte_acl/acl_run.c b/lib/librte_acl/acl_run.c > > deleted file mode 100644 > > index e3d9fc1..000 > > --- a/lib/librte_acl/acl_run.c > > +++ /dev/null > > @@ -1,944 +0,0 @@ > > -/*- > > - * BSD LICENSE > > - * > > - * Copyright(c) 2010-2014 Intel Corporation. All rights reserved. > > - * All rights reserved. > > - * > > - * Redistribution and use in source and binary forms, with or without > > - * modification, are permitted provided that the following conditions > > > > + > > +#define__func_resolve_priority__ resolve_priority_scalar > > +#define__func_match_check__acl_match_check_scalar > > +#include "acl_match_check.def" > > + > I get this lets you make some more
[dpdk-dev] [PATCHv2] librte_acl make it build/work for 'default' target
On Fri, Aug 08, 2014 at 11:49:58AM +, Ananyev, Konstantin wrote: > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > Sent: Thursday, August 07, 2014 9:12 PM > > To: Ananyev, Konstantin > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCHv2] librte_acl make it build/work for > > 'default' target > > > > On Thu, Aug 07, 2014 at 07:31:03PM +0100, Konstantin Ananyev wrote: > > > Make ACL library to build/work on 'default' architecture: > > > - make rte_acl_classify_scalar really scalar > > > (make sure it wouldn't use sse4 instrincts through resolve_priority()). > > > - Provide two versions of rte_acl_classify code path: > > > rte_acl_classify_sse() - could be build and used only on systems with > > > sse4.2 > > > and upper, return -ENOTSUP on lower arch. > > > rte_acl_classify_scalar() - a slower version, but could be build and > > > used > > > on all systems. > > > - keep common code shared between these two codepaths. > > > > > > v2 chages: > > > run-time selection of most appropriate code-path for given ISA. > > > By default the highest supprted one is selected. > > > User can still override that selection by manually assigning new value to > > > the global function pointer rte_acl_default_classify. > > > rte_acl_classify() becomes a macro calling whatever > > > rte_acl_default_classify > > > points to. > > > > > > > > > Signed-off-by: Konstantin Ananyev > > > > This is alot better thank you. A few remaining issues. > > My comments inline too. > Thanks > Konstantin > > > > > > --- > > > app/test-acl/main.c| 13 +- > > > lib/librte_acl/Makefile| 5 +- > > > lib/librte_acl/acl_bld.c | 5 +- > > > lib/librte_acl/acl_match_check.def | 92 > > > lib/librte_acl/acl_run.c | 944 > > > - > > > lib/librte_acl/acl_run.h | 220 + > > > lib/librte_acl/acl_run_scalar.c| 197 > > > lib/librte_acl/acl_run_sse.c | 630 + > > > lib/librte_acl/rte_acl.c | 15 + > > > lib/librte_acl/rte_acl.h | 24 +- > > > 10 files changed, 1189 insertions(+), 956 deletions(-) > > > create mode 100644 lib/librte_acl/acl_match_check.def > > > delete mode 100644 lib/librte_acl/acl_run.c > > > create mode 100644 lib/librte_acl/acl_run.h > > > create mode 100644 lib/librte_acl/acl_run_scalar.c > > > create mode 100644 lib/librte_acl/acl_run_sse.c > > > > > > diff --git a/app/test-acl/main.c b/app/test-acl/main.c > > > index d654409..45c6fa6 100644 > > > --- a/app/test-acl/main.c > > > +++ b/app/test-acl/main.c > > > @@ -787,6 +787,10 @@ acx_init(void) > > > /* perform build. */ > > > ret = rte_acl_build(config.acx, &cfg); > > > > > > + /* setup default rte_acl_classify */ > > > + if (config.scalar) > > > + rte_acl_default_classify = rte_acl_classify_scalar; > > > + > > Exporting this variable as part of the ABI is a bad idea. If the prototype > > of > > the function changes you have to update all your applications. > > If the prototype of rte_acl_classify will change, most likely you'll have to > update code that uses it anyway. > Why? If you hide this from the application, changes to the internal implementation will also be invisible. When building as a DSO, an application will be able to transition between libraries without the need for a rebuild. > > Make the pointer > > an internal symbol and set it using a get/set routine with an enum to > > represent > > the path to choose. That will help isolate the ABI from the internal > > implementation. > > That's was my first intention too. > But then I realised that if we'll make it internal, then we'll need to make > rte_acl_classify() a proper function > and it will cost us extra call (or jump). Thats true, but I don't see that as a problem. We're not talking about a hot code path here, its a setup function. Or do you think that an application will be switching between classification functions on every classify operation? > Also I think user should have an ability to change default classify code path > without modifying/rebuilding acl library. I agree, but both the methods we are advocating for allow that. Its really just a question of exposing the mechanism as data or text in the binary. Exposing it as data comes with implicit ABI constraints that are less prevalanet when done as code entry points. > For example: a bug in an optimised code path is discovered, or user may want > to implement and use his own version of classify(). In the case of a bug in the optimized path, you just fix the bug. If you want to provide your own classification function, thats fine I suppose, but that seems completely outside the scope of what we're trying to do here. Its not adventageous to just throw that in there. If you want to be able to provide your own classifier function, lets at least take some time to make sure that the function prototype is
[dpdk-dev] [PATCHv2] librte_acl make it build/work for 'default' target
> From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Friday, August 08, 2014 1:25 PM > To: Ananyev, Konstantin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCHv2] librte_acl make it build/work for 'default' > target > > On Fri, Aug 08, 2014 at 11:49:58AM +, Ananyev, Konstantin wrote: > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > > Sent: Thursday, August 07, 2014 9:12 PM > > > To: Ananyev, Konstantin > > > Cc: dev at dpdk.org > > > Subject: Re: [dpdk-dev] [PATCHv2] librte_acl make it build/work for > > > 'default' target > > > > > > On Thu, Aug 07, 2014 at 07:31:03PM +0100, Konstantin Ananyev wrote: > > > > Make ACL library to build/work on 'default' architecture: > > > > - make rte_acl_classify_scalar really scalar > > > > (make sure it wouldn't use sse4 instrincts through resolve_priority()). > > > > - Provide two versions of rte_acl_classify code path: > > > > rte_acl_classify_sse() - could be build and used only on systems with > > > > sse4.2 > > > > and upper, return -ENOTSUP on lower arch. > > > > rte_acl_classify_scalar() - a slower version, but could be build and > > > > used > > > > on all systems. > > > > - keep common code shared between these two codepaths. > > > > > > > > v2 chages: > > > > run-time selection of most appropriate code-path for given ISA. > > > > By default the highest supprted one is selected. > > > > User can still override that selection by manually assigning new value > > > > to > > > > the global function pointer rte_acl_default_classify. > > > > rte_acl_classify() becomes a macro calling whatever > > > > rte_acl_default_classify > > > > points to. > > > > > > > > > > > > Signed-off-by: Konstantin Ananyev > > > > > > This is alot better thank you. A few remaining issues. > > > > My comments inline too. > > Thanks > > Konstantin > > > > > > > > > --- > > > > app/test-acl/main.c| 13 +- > > > > lib/librte_acl/Makefile| 5 +- > > > > lib/librte_acl/acl_bld.c | 5 +- > > > > lib/librte_acl/acl_match_check.def | 92 > > > > lib/librte_acl/acl_run.c | 944 > > > > - > > > > lib/librte_acl/acl_run.h | 220 + > > > > lib/librte_acl/acl_run_scalar.c| 197 > > > > lib/librte_acl/acl_run_sse.c | 630 + > > > > lib/librte_acl/rte_acl.c | 15 + > > > > lib/librte_acl/rte_acl.h | 24 +- > > > > 10 files changed, 1189 insertions(+), 956 deletions(-) > > > > create mode 100644 lib/librte_acl/acl_match_check.def > > > > delete mode 100644 lib/librte_acl/acl_run.c > > > > create mode 100644 lib/librte_acl/acl_run.h > > > > create mode 100644 lib/librte_acl/acl_run_scalar.c > > > > create mode 100644 lib/librte_acl/acl_run_sse.c > > > > > > > > diff --git a/app/test-acl/main.c b/app/test-acl/main.c > > > > index d654409..45c6fa6 100644 > > > > --- a/app/test-acl/main.c > > > > +++ b/app/test-acl/main.c > > > > @@ -787,6 +787,10 @@ acx_init(void) > > > > /* perform build. */ > > > > ret = rte_acl_build(config.acx, &cfg); > > > > > > > > + /* setup default rte_acl_classify */ > > > > + if (config.scalar) > > > > + rte_acl_default_classify = rte_acl_classify_scalar; > > > > + > > > Exporting this variable as part of the ABI is a bad idea. If the > > > prototype of > > > the function changes you have to update all your applications. > > > > If the prototype of rte_acl_classify will change, most likely you'll have > > to update code that uses it anyway. > > > Why? If you hide this from the application, changes to the internal > implementation will also be invisible. When building as a DSO, an application > will be able to transition between libraries without the need for a rebuild. Because rte_acl_classify() is part of the ACL API that users use. If we'll add/modify its parameters and/or return value - users would have to change their apps anyway. > > > Make the pointer > > > an internal symbol and set it using a get/set routine with an enum to > > > represent > > > the path to choose. That will help isolate the ABI from the internal > > > implementation. > > > > That's was my first intention too. > > But then I realised that if we'll make it internal, then we'll need to make > > rte_acl_classify() a proper function > > and it will cost us extra call (or jump). > Thats true, but I don't see that as a problem. We're not talking about a hot > code path here, its a setup function. I am talking not about rte_acl_select_classify() but about rte_acl_classify() itself (not code path). If I'll make rte_acl_default_classify statitc, the rte_acl_classiy() would need to become a real function and it'll be something like that: ->call rte_acl_acl_classify ---> load rte_acl_calssify_default value into the reg ---> jmp (*reg) > Or do you think that an application will > be switching between classification fu
[dpdk-dev] [PATCHv2] librte_acl make it build/work for 'default' target
On Fri, Aug 08, 2014 at 01:09:34PM +, Ananyev, Konstantin wrote: > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > Sent: Friday, August 08, 2014 1:25 PM > > To: Ananyev, Konstantin > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCHv2] librte_acl make it build/work for > > 'default' target > > > > On Fri, Aug 08, 2014 at 11:49:58AM +, Ananyev, Konstantin wrote: > > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > > > Sent: Thursday, August 07, 2014 9:12 PM > > > > To: Ananyev, Konstantin > > > > Cc: dev at dpdk.org > > > > Subject: Re: [dpdk-dev] [PATCHv2] librte_acl make it build/work for > > > > 'default' target > > > > > > > > On Thu, Aug 07, 2014 at 07:31:03PM +0100, Konstantin Ananyev wrote: > > > > > Make ACL library to build/work on 'default' architecture: > > > > > - make rte_acl_classify_scalar really scalar > > > > > (make sure it wouldn't use sse4 instrincts through > > > > > resolve_priority()). > > > > > - Provide two versions of rte_acl_classify code path: > > > > > rte_acl_classify_sse() - could be build and used only on systems > > > > > with sse4.2 > > > > > and upper, return -ENOTSUP on lower arch. > > > > > rte_acl_classify_scalar() - a slower version, but could be build > > > > > and used > > > > > on all systems. > > > > > - keep common code shared between these two codepaths. > > > > > > > > > > v2 chages: > > > > > run-time selection of most appropriate code-path for given ISA. > > > > > By default the highest supprted one is selected. > > > > > User can still override that selection by manually assigning new > > > > > value to > > > > > the global function pointer rte_acl_default_classify. > > > > > rte_acl_classify() becomes a macro calling whatever > > > > > rte_acl_default_classify > > > > > points to. > > > > > > > > > > > > > > > Signed-off-by: Konstantin Ananyev > > > > > > > > This is alot better thank you. A few remaining issues. > > > > > > My comments inline too. > > > Thanks > > > Konstantin > > > > > > > > > > > > --- > > > > > app/test-acl/main.c| 13 +- > > > > > lib/librte_acl/Makefile| 5 +- > > > > > lib/librte_acl/acl_bld.c | 5 +- > > > > > lib/librte_acl/acl_match_check.def | 92 > > > > > lib/librte_acl/acl_run.c | 944 > > > > > - > > > > > lib/librte_acl/acl_run.h | 220 + > > > > > lib/librte_acl/acl_run_scalar.c| 197 > > > > > lib/librte_acl/acl_run_sse.c | 630 + > > > > > lib/librte_acl/rte_acl.c | 15 + > > > > > lib/librte_acl/rte_acl.h | 24 +- > > > > > 10 files changed, 1189 insertions(+), 956 deletions(-) > > > > > create mode 100644 lib/librte_acl/acl_match_check.def > > > > > delete mode 100644 lib/librte_acl/acl_run.c > > > > > create mode 100644 lib/librte_acl/acl_run.h > > > > > create mode 100644 lib/librte_acl/acl_run_scalar.c > > > > > create mode 100644 lib/librte_acl/acl_run_sse.c > > > > > > > > > > diff --git a/app/test-acl/main.c b/app/test-acl/main.c > > > > > index d654409..45c6fa6 100644 > > > > > --- a/app/test-acl/main.c > > > > > +++ b/app/test-acl/main.c > > > > > @@ -787,6 +787,10 @@ acx_init(void) > > > > > /* perform build. */ > > > > > ret = rte_acl_build(config.acx, &cfg); > > > > > > > > > > + /* setup default rte_acl_classify */ > > > > > + if (config.scalar) > > > > > + rte_acl_default_classify = rte_acl_classify_scalar; > > > > > + > > > > Exporting this variable as part of the ABI is a bad idea. If the > > > > prototype of > > > > the function changes you have to update all your applications. > > > > > > If the prototype of rte_acl_classify will change, most likely you'll have > > > to update code that uses it anyway. > > > > > Why? If you hide this from the application, changes to the internal > > implementation will also be invisible. When building as a DSO, an > > application > > will be able to transition between libraries without the need for a rebuild. > > Because rte_acl_classify() is part of the ACL API that users use. > If we'll add/modify its parameters and/or return value - users would have to > change their apps anyway. > Thats not at all true. With API versioning scripts you can make several versions of the same function with different prototypes as future needs dictate. Hiding the internal implementation just makes that easier. > > > > Make the pointer > > > > an internal symbol and set it using a get/set routine with an enum to > > > > represent > > > > the path to choose. That will help isolate the ABI from the internal > > > > implementation. > > > > > > That's was my first intention too. > > > But then I realised that if we'll make it internal, then we'll need to > > > make rte_acl_classify() a proper function > > > and it will cost us extra call (or jump). > > Thats true, but I don't see that as a problem.
[dpdk-dev] Is VFIO driver's performance better than IGB_UIO?
* Vincent JARDIN (vincent.jardin at 6wind.com) wrote: > > My cpu is "Intel(R) Xeon(R) CPU E5620 @ 2.40GHz" > > It is a Westmere if I am correct. So,use UIO. My experience is that the CPU isn't as an important part of the platform as the chipset. IOW, VFIO requires full IOMMU isolation, and the IOMMU cost depends on the chipset. Vincent, is that what you were implying by cpu, or do you see something else? thanks, -chris
