[dpdk-dev] random pkt generator PMD
On Wed, Jun 15, 2016 at 4:03 PM, Dumitrescu, Cristian < cristian.dumitrescu at intel.com> wrote: > > > > -Original Message- > > From: Yerden Zhumabekov [mailto:e_zhumabekov at sts.kz] > > Sent: Wednesday, June 15, 2016 1:55 PM > > To: Dumitrescu, Cristian ; Panu > Matilainen > > ; dev at dpdk.org > > Subject: Re: [dpdk-dev] random pkt generator PMD > > > > > > > > On 15.06.2016 18:25, Dumitrescu, Cristian wrote: > > > > So add a loop-mode to pcap pmd? > > >>> It would be nice to have an option like "...,rewind=1,...". > > >> As Cristian points out in > > >> http://dpdk.org/ml/archives/dev/2016-June/041589.html, the current > > pmd > > >> behavior of stopping is the odd man out in the pmd crowd. > > >> > > >> Rather than whether to rewind or not, I'd make the number of loops > > >> configurable, defaulting to forever and 1 being the equal to current > > >> behavior. > > >> > > >>- Panu - > > > +1 > > > > I'm afraid, all packets from pcap file would need to be preloaded to > > memory. Otherwise, each loop would infer pcap_open/pcap_close(), am I > > wrong? > > This exactly what the code in source port is doing. > > Basically, this is optimized for the case when number of packets in the > PCAP file is relatively small, so the PCAP memory footprint when loaded > into memory is small so it fits the L1/L2 cache. Provides traffic > generation capability when performance measurements are not key: testing, > code development on your laptop while on board of a plane, simulation > environments, etc. > > When the PCAP is large (e.g. capture of the traffic in your local cloud > for 2 mins), then PCAP memory gets swapped to disk and performance > obviously drops. Still better than opening PCAC for each packet. Useful for > e.g. IDS/IPS testing. > If you are after continuous traffic that varies all the time in high performance rather than loop the same pcap over and over again, check out the T-Rex traffic generator which is an open source and dpdk based. https://trex-tgn.cisco.com/ /Arnon
[dpdk-dev] [RFC] Yet another option for DPDK options
I On Fri, Jun 3, 2016 at 10:23 PM, Wiles, Keith wrote: > > On 6/3/16, 2:18 PM, "Neil Horman" wrote: > > >On Fri, Jun 03, 2016 at 07:07:50PM +, Wiles, Keith wrote: > >> On 6/3/16, 2:00 PM, "dev on behalf of Wiles, Keith" < > dev-bounces at dpdk.org on behalf of keith.wiles at intel.com> wrote: > >> > >> >On 6/3/16, 1:52 PM, "Arnon Warshavsky" arnon at qwilt.com>> wrote: > >> > > >> > > >> > > >> >On Fri, Jun 3, 2016 at 9:38 PM, Neil Horman <mailto:nhorman at tuxdriver.com>> wrote: > >> >On Fri, Jun 03, 2016 at 06:29:13PM +, Wiles, Keith wrote: > >> >> > >> >> On 6/3/16, 12:44 PM, "Neil Horman" nhorman at tuxdriver.com>> wrote: > >> >> > >> >> >On Fri, Jun 03, 2016 at 04:04:14PM +, Wiles, Keith wrote: > >> >> >> Sorry, I deleted all of the text as it was getting a bit long. > >> >> >> > >> >> >> Here are my thoughts as of now, which is a combination of many > suggestions I read from everyone?s emails. I hope this is not too hard to > understand. > >> >> >> > >> >> >> - Break out the current command line options out of the DPDK > common code and move into a new lib. > >> >> >> - At this point I was thinking of keeping the > rte_eal_init(args, argv) API and just have it pass the args/argv to the new > lib to create the data storage. > >> >> >> - Maybe move the rte_eal_init() API to the new lib or keep > it in the common eal code. Do not want to go hog wild. > >> >> >> - The rte_eal_init(args, argv) would then call to the new API > rte_eal_initialize(void), which in turn queries the data storage. (still > thinking here) > >> >> >These three items seem to be the exact opposite of my suggestion. > The point of > >> >> >this change was to segregate the parsing of configuration away from > the > >> >> >initalization dpdk using that configurtion. By keeping > rte_eal_init in such a > >> >> >way that the command line is directly passed into it, you've not > changed that > >> >> >implicit binding to command line options. > >> >> > >> >> Neil, > >> >> > >> >> You maybe reading the above wrong or I wrote it wrong, which is a > high possibility. I want to move the command line parsing out of DPDK an > into a library, but I still believe I need to provide some backward > compatibility for ABI and to reduce the learning curve. The current > applications can still call the rte_eal_init(), which then calls the new > lib parser for dpdk command line options and then calls > rte_eal_initialize() or move to the new API rte_eal_initialize() preceded > by a new library call to parse the old command line args. At some point we > can deprecate the rte_eal_init() if we think it is reasonable. > >> >> > >> >> > > >> >> >I can understand if you want to keep rte_eal_init as is for ABI > purposes, but > >> >> >then you should create an rte_eal_init2(foo), where foo is some > handle to in > >> >> >memory parsed configuration, so that applications can preform that > separation. > >> >> > >> >> I think you describe what I had planned here. The > rte_eal_initialize() routine is the new rte_eal_init2() API and the > rte_eal_init() was only for backward compatibility was my thinking. I > figured the argument to rte_eal_initialize() would be something to be > decided, but it will mostly likely be some type of pointer to the storage. > >> >> > >> >> I hope that clears that up, but let me know. > >> >> > >> >yes, that clarifies your thinking, and I agree with it. Thank you! > >> >Neil > >> > > >> >> ++Keith > >> >> > >> >> > > >> >> >Neil > >> >> > > >> >> >> - The example apps args needs to be passed to the examples as > is for now, then we can convert them one at a time if needed. > >> >> >> > >> >> >> - I would like to keep the storage of the data separate from the > file parser as they can use the ?set? routines to build the data storage up. > >> >> >> - Keeping them split allows for new parsers to be created, > while keeping the data storage from changing. > >> >> >> - The rte_cfg code
[dpdk-dev] [RFC] Yet another option for DPDK options
On Fri, Jun 3, 2016 at 9:38 PM, Neil Horman wrote: > On Fri, Jun 03, 2016 at 06:29:13PM +, Wiles, Keith wrote: > > > > On 6/3/16, 12:44 PM, "Neil Horman" wrote: > > > > >On Fri, Jun 03, 2016 at 04:04:14PM +, Wiles, Keith wrote: > > >> Sorry, I deleted all of the text as it was getting a bit long. > > >> > > >> Here are my thoughts as of now, which is a combination of many > suggestions I read from everyone?s emails. I hope this is not too hard to > understand. > > >> > > >> - Break out the current command line options out of the DPDK common > code and move into a new lib. > > >> - At this point I was thinking of keeping the rte_eal_init(args, > argv) API and just have it pass the args/argv to the new lib to create the > data storage. > > >> - Maybe move the rte_eal_init() API to the new lib or keep it in > the common eal code. Do not want to go hog wild. > > >> - The rte_eal_init(args, argv) would then call to the new API > rte_eal_initialize(void), which in turn queries the data storage. (still > thinking here) > > >These three items seem to be the exact opposite of my suggestion. The > point of > > >this change was to segregate the parsing of configuration away from the > > >initalization dpdk using that configurtion. By keeping rte_eal_init in > such a > > >way that the command line is directly passed into it, you've not > changed that > > >implicit binding to command line options. > > > > Neil, > > > > You maybe reading the above wrong or I wrote it wrong, which is a high > possibility. I want to move the command line parsing out of DPDK an into a > library, but I still believe I need to provide some backward compatibility > for ABI and to reduce the learning curve. The current applications can > still call the rte_eal_init(), which then calls the new lib parser for dpdk > command line options and then calls rte_eal_initialize() or move to the new > API rte_eal_initialize() preceded by a new library call to parse the old > command line args. At some point we can deprecate the rte_eal_init() if we > think it is reasonable. > > > > > > > >I can understand if you want to keep rte_eal_init as is for ABI > purposes, but > > >then you should create an rte_eal_init2(foo), where foo is some handle > to in > > >memory parsed configuration, so that applications can preform that > separation. > > > > I think you describe what I had planned here. The rte_eal_initialize() > routine is the new rte_eal_init2() API and the rte_eal_init() was only for > backward compatibility was my thinking. I figured the argument to > rte_eal_initialize() would be something to be decided, but it will mostly > likely be some type of pointer to the storage. > > > > I hope that clears that up, but let me know. > > > yes, that clarifies your thinking, and I agree with it. Thank you! > Neil > > > ++Keith > > > > > > > >Neil > > > > > >> - The example apps args needs to be passed to the examples as is > for now, then we can convert them one at a time if needed. > > >> > > >> - I would like to keep the storage of the data separate from the file > parser as they can use the ?set? routines to build the data storage up. > > >> - Keeping them split allows for new parsers to be created, while > keeping the data storage from changing. > > >> - The rte_cfg code could be modified to use the new configuration if > someone wants to take on that task ? > > >> > > >> - Next is the data storage and how we can access the data in a clean > simple way. > > >> - I want to have some simple level of hierarchy in the data. > > >> - Having a string containing at least two levels > ?primary:secondary?. > > >> - Primary string is something like ?EAL? or ?Pktgen? or > ?testpmd? to divide the data storage into logical major groups. > > >> - The primary allows us to have groups and then we can have > common secondary strings in different groups if needed. > > >> - Secondary string can be whatever the developer of that group > would like e.g. simple ?EAL:foobar?, two levels ?testpmd:foo.bar? > > >> > > >> - The secondary string is treated as a single string if it has a > hierarchy or not, but referencing a single value in the data storage. > > >> - Key value pairs (KVP) or a hashmap data store. > > >> - The key here is the whole string ?EAL:foobar? not just > ?foobar? secondary string. > > >>- If we want to have the two split I am ok with that as > well meaning the API would be: > > >> rte_map_get(mapObj, ?EAL?, ?foo.bar?); > > >> rte_map_set(mapObj, ?EAL?, ?foo.bar?, value); > > >>- Have the primary as a different section in the data > store, would allow for dumping that section maybe easier, not sure. > > >> - I am leaning toward > > >> - Not going to try splitting up the string or parse it as it is > up to the developer to make it unique in the data store. > > >> - Use a code design to make the strings simple to use without having >
[dpdk-dev] [RFC] Yet another option for DPDK options
On Fri, Jun 3, 2016 at 3:53 PM, Panu Matilainen wrote:
> On 06/03/2016 03:01 PM, Arnon Warshavsky wrote:
>
>>
>>
>> On Fri, Jun 3, 2016 at 2:50 PM, Neil Horman > <mailto:nhorman at tuxdriver.com>> wrote:
>>
>> On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote:
>> > On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote:
>> > > On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote:
>> > > > On Thu, Jun 02, 2016 at 07:41:10PM +, Wiles, Keith wrote:
>> > > > >
>> > > > > On 6/2/16, 12:11 PM, "Neil Horman" > <mailto:nhorman at tuxdriver.com>> wrote:
>> > > > >
>> > > > > >
>> > > > > >1) The definition of a config structure that can be passed
>> to rte_eal_init,
>> > > > > >defining the configuration for that running process
>> > > > >
>> > > > > Having a configuration structure means we have to have an
>> ABI change to that structure anytime we add or remove an option. I
>> was thinking a very simple DB of some kind would be better. Have the
>> code query the DB to obtain the needed information. The APIs used to
>> query and set the DB needs to be very easy to use as well.
>> > > >
>> > > > Thats a fair point. A decent starting point is likely a
>> simple struct that
>> > > > looks like this:
>> > > >
>> > > > struct key_vals {
>> > > > char *key;
>> > > > union {
>> > > > ulong longval;
>> > > > void *ptrval;
>> > > > } value;
>> > > > };
>> > > >
>> > > > struct config {
>> > > > size_t count;
>> > > > struct key_vals kvp[0];
>> > > > };
>> > > >
>> > > > >
>> > > > > Maybe each option can define its own structure if needed or
>> just a simple variable type can be used for the basic types (int,
>> string, bool, ?)
>> > > > >
>> > > > Well, if you have config sections that require mulitiple
>> elements, I'd handle
>> > > > that with naming, i.e. if you have a config group that has an
>> int and char
>> > > > value, I'd name them "group.intval", and "group.charval", so
>> they are
>> > > > independently searchable, but linked from a nomenclature
>> standpoint.
>> > > >
>> > > > > Would this work better in the long run, does a fixed
>> structure still make sense?
>> > > > >
>> > > > No. I think you're ABI concerns are valid, but the above is
>> likely a good
>> > > > starting point to address them.
>> > > >
>> > > > Best
>> > > > Neil
>> > >
>> > > I'll throw out one implementation idea here that I looked at
>> previously, for
>> > > the reason that it was simple enough implement with existing code.
>> > >
>> > > We already have the cfgfile library which works with name/value
>> pairs read from
>> > > ini files on disk. However, it would be easy enough to add
>> couple of APIs to
>> > > that to allow the user to "set" values inside an ini structure
>> as well. With
>> > > that done we can then just add a new eal_init api which takes a
>> single
>> > > "struct rte_cfgfile *" as parameter. For those apps that want to
>> just use
>> > > inifiles for configuration straight, they can then do:
>> > >
>> > > cfg = rte_cfgfile_load("my_cfg_file");
>> > > rte_eal_newinit(cfg);
>> > >
>> > > Those who want a different config can instead do:
>> > >
>> > > cfg = rte_cfgfile_new();
>> > > rte_cfgfile_add_section(cfg, "dpdk");
>> > > foreach_eal_setting_wanted:
>> > > rte_cfgfile_set(cfg, "dpdk", mysetting, myvalue);
>> > > rte_eal_newinit(cfg);
>> > >
>> > From chatting to a couple of other DPDK dev's here I s
[dpdk-dev] [RFC] Yet another option for DPDK options
On Fri, Jun 3, 2016 at 2:50 PM, Neil Horman wrote:
> On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote:
> > On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote:
> > > On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote:
> > > > On Thu, Jun 02, 2016 at 07:41:10PM +, Wiles, Keith wrote:
> > > > >
> > > > > On 6/2/16, 12:11 PM, "Neil Horman" wrote:
> > > > >
> > > > > >
> > > > > >1) The definition of a config structure that can be passed to
> rte_eal_init,
> > > > > >defining the configuration for that running process
> > > > >
> > > > > Having a configuration structure means we have to have an ABI
> change to that structure anytime we add or remove an option. I was thinking
> a very simple DB of some kind would be better. Have the code query the DB
> to obtain the needed information. The APIs used to query and set the DB
> needs to be very easy to use as well.
> > > >
> > > > Thats a fair point. A decent starting point is likely a simple
> struct that
> > > > looks like this:
> > > >
> > > > struct key_vals {
> > > > char *key;
> > > > union {
> > > > ulong longval;
> > > > void *ptrval;
> > > > } value;
> > > > };
> > > >
> > > > struct config {
> > > > size_t count;
> > > > struct key_vals kvp[0];
> > > > };
> > > >
> > > > >
> > > > > Maybe each option can define its own structure if needed or just a
> simple variable type can be used for the basic types (int, string, bool, ?)
> > > > >
> > > > Well, if you have config sections that require mulitiple elements,
> I'd handle
> > > > that with naming, i.e. if you have a config group that has an int
> and char
> > > > value, I'd name them "group.intval", and "group.charval", so they are
> > > > independently searchable, but linked from a nomenclature standpoint.
> > > >
> > > > > Would this work better in the long run, does a fixed structure
> still make sense?
> > > > >
> > > > No. I think you're ABI concerns are valid, but the above is likely a
> good
> > > > starting point to address them.
> > > >
> > > > Best
> > > > Neil
> > >
> > > I'll throw out one implementation idea here that I looked at
> previously, for
> > > the reason that it was simple enough implement with existing code.
> > >
> > > We already have the cfgfile library which works with name/value pairs
> read from
> > > ini files on disk. However, it would be easy enough to add couple of
> APIs to
> > > that to allow the user to "set" values inside an ini structure as
> well. With
> > > that done we can then just add a new eal_init api which takes a single
> > > "struct rte_cfgfile *" as parameter. For those apps that want to just
> use
> > > inifiles for configuration straight, they can then do:
> > >
> > > cfg = rte_cfgfile_load("my_cfg_file");
> > > rte_eal_newinit(cfg);
> > >
> > > Those who want a different config can instead do:
> > >
> > > cfg = rte_cfgfile_new();
> > > rte_cfgfile_add_section(cfg, "dpdk");
> > > foreach_eal_setting_wanted:
> > > rte_cfgfile_set(cfg, "dpdk", mysetting, myvalue);
> > > rte_eal_newinit(cfg);
> > >
> > From chatting to a couple of other DPDK dev's here I suspect I may not
> have
> > been entirely clear here with this example. What is being shown above is
> building
> > up a "config-file" in memory - or rather a config structure which
> happens to
> > have the idea of sections and values as an ini file has. There is no
> actual
> > file ever being written to disk, and for those using any non-ini config
> file
> > structure for their app, the code overhead of using the APIs above
> should be
> > pretty much the same as building up any other set of key-value pairs in
> > memory to pass to an init function.
> >
> > Hope this is a little clearer now.
> >
> I'm fine with the idea of reusing the config file library that currently
> exists,
> or more to the point, modifying it to be usable as a configuration API,
> rather
> than a configuration file parser. My primary interest is in separating
> the user
> configuration mechanism from the internal library configuration lookup
> mechanism. What I would really like to be able to see is application
> developers
> have the flexibiilty to choose their own configuration method and format,
> and
> programatically build a configuration for the dpdk on a per-instance basis
> prior
> to calling rte_eal_init
>
> It seems like this approach satisfies that requirement
> Neil
>
>
If the there is no configuration structure , rather an opaque configuration
key/value store ,
the user applications can set and get knobs that are not seen by anyone
(library) that does not know them by name
e.g
int num_nodes = getCfgInt ( cfgObject , "eal" , "num_numa_nodes");
int delay = getCfgInt ( cfgObject , "drivers.ixgbe" , "some_delay");
setCfgInt (cfgObject , "my_app" , "num_days" , 7);
setCfgString (cfgObject , "my_app" , "best_day" , "Wednesday");
/Arnon
[dpdk-dev] [RFC] Yet another option for DPDK options
On Wed, Jun 1, 2016 at 7:18 PM, Bruce Richardson wrote: > On Wed, Jun 01, 2016 at 10:58:41AM -0500, Jay Rolette wrote: > > On Wed, Jun 1, 2016 at 10:00 AM, Wiles, Keith > wrote: > > > > > Started from the link below, but did not want to highjack the thread. > > > http://dpdk.org/ml/archives/dev/2016-June/040021.html > > > > > > I was thinking about this problem from a user perspective and command > line > > > options are very difficult to manage specifically when you have a large > > > number of options as we have in dpdk. I see all of these options as a > type > > > of database of information for the DPDK and the application, because > the > > > application command line options are also getting very complex as well. > > > > > > I have been looking at a number of different options here and the > > > direction I was thinking was using a file for the options and > > > configurations with the data in a clean format. It could have been a > INI > > > file or JSON or XML, but they all seem to have some problems I do not > like. > > > The INI file is too flat and I wanted a hierarchy in the data, the JSON > > > data is similar and XML is just hard to read. I wanted to be able to > manage > > > multiple applications and possible system the DPDK/app runs. The > problem > > > with the above formats is they are just data and not easy to make > decisions > > > about the system and applications at runtime. > > > > > > > INI format is simplest for users to read, but if you really need > hierarchy, > > JSON will do that just fine. Not sure what you mean by "JSON data is > > similar"... > > > > > I'd be quite concerned if we start needing lots of hierarchies for > configuration. > > I'd really just like to see ini file format used for this because: > * it's a well understood, simple format > * very easily human readable and editable > * lots of support for it in lots of languages > * hierarchies are possible in it too - just not as easy as in other formats > though. [In a previous life I worked with ini files which had address > hierarchies 6-levels deep in them. It wasn't hard to work with] > * it works well with grep since you must have one value per-line > * it allows comments > * we already have a DPDK library for parsing them > > However, for me the biggest advantage of using something like ini is that > it > would force us to keep things simple! > > I'd stay away from formats like json or XML that are designed for > serializing > entire objects or structures, and look for something that allows us to just > specify configuration values. > > Regards, > /Bruce > > +1 for a single cfg file parameter +1 for ini simplicity /Arnon
[dpdk-dev] removing mbuf error flags
On Fri, Apr 29, 2016 at 9:24 PM, Jay Rolette wrote: > On Fri, Apr 29, 2016 at 1:16 PM, Don Provan wrote: > > > >From: Olivier Matz [mailto:olivier.matz at 6wind.com] > > >Subject: [dpdk-dev] removing mbuf error flags > > > > > >My opinion is that invalid packets should not be given to the > application > > and only a statistic counter should be incremented. > > > > The idea of an application that handles bad packets is perfectly valid. > > Most applications don't want to see them, of course, but, conceptually, > > some applications would want to ask for bad packets because they are > > specifically designed to handle various networking problems including > those > > that result in bad packets that the application can look at and report. > > Furthermore, it makes technical sense for DPDK to support such > applications. > > > > Having said that, I have no idea if that's why that field was added, and > I > > don?t myself care if DPDK provides that feature in the future. I just > > thought I'd put the idea out there in case it makes any difference to > you. > > If it were me, I'd probably decide it isn't hurting anything and not > bother > > to remove it in case some day someone wants to implement that feature in > > one driver or another. > > > > Yep. Pretty much any networking security product needs to see malformed > packets. > > Jay > +1 for letting the application see bad packets and decide what to do with them. We had some zero order insertion issues in the past where the ability to let the application capture malformed/unexpected packets was very helpful. /Arnon.
[dpdk-dev] DPDK namespace
On Tue, Apr 5, 2016 at 5:13 PM, Trahe, Fiona wrote: > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > Sent: Tuesday, April 05, 2016 2:57 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] DPDK namespace > > > > DPDK is going to be more popular in Linux distributions. > > It means people will have some DPDK files in their /usr/include and some > DPDK > > libraries on their system. > > > > Let's imagine someone trying to compile an application which needs > > rte_ethdev.h. He has to figure out that this "rte header" is provided by > the DPDK. > > Hopefully it will be explained on StackOverflow that RTE stands for DPDK. > > Then someone else will try to run a binary without having installed the > DPDK > > libraries. The linker will require libethdev.so (no prefix here). > > StackOverflow will probably have another good answer (among wrong ones): > > "Hey Sherlock Holmes, have you tried to install the DPDK library?" > > Followed by an insight: "You know, the DPDK naming is weird..." > > And we could continue the story with developers having some naming clash > > because of some identifiers not prefixed at all. > > > > The goal of this email is to get some feedback on how important it is to > fix the > > DPDK namespace. > > > > If there is enough agreement that we should do something, I suggest to > > introduce the "dpdk_" prefix slowly and live with both "rte_" and "dpdk_" > > during some time. > > We could start using the new prefix for the new APIs (example: crypto) > or when > > there is a significant API break (example: mempool). > > > > Opinions welcome! > I don't have an opinion on how important it is to fix the namespace, > though it does seem like a good idea. > However if it's to be done, in my opinion it should be completed quickly > or will just cause more confusion. > So if rte_cryptoxxx becomes dpdk_cryptoxxx all other libraries should > follow in next release or two, with > the resulting ABI compatibility handling. Maybe with dual naming handled > for several releases, but a > clear end date when all are converted. > Else there will be many years with a mix of rte_ and dpdk_ > > Googling rte functions or error codes usually takes you to dpdk dev email archive so I don't think it is that much difficult to figure out where rte comes from. Other than that , except for my own refactoring pains when replacing a dpdk version, I do not see a major reason why not. If Going for dpdk_ prefix, I agree with the quick death approach. /Arnon
[dpdk-dev] Performance degradation with multiple ports
Hi Swamy A somewhat similar degradation (though not with l2fwd) was experienced by us as described here http://dev.dpdk.narkive.com/OL0KiHns/dpdk-dev-missing-prefetch-in-non-vector-rx-function In our case it surfaced for not using the default configuration and working in non-vector mode, and it behaved the same for both ixgbe and i40e. /Arnon On Tue, Feb 23, 2016 at 5:24 AM, SwamZ wrote: > Hi, > > I am trying to find the maximum IO core performance with DPDK-2.2 code > using l2fwd application. I got the following number in comparison with > DPDK-1.7 code. > > >One Port Two ports > > DPDK 2.2 14.86Mpps per port 11.8Mpps per port > > DPDK 1.7 11.8Mpps per port 11.8Mpps per port > > > > Traffic rate from Router tester: 64bytes packet with 100% line rate > (14.86Mpps per port) > > CPU Speed : 3.3GHz > > NIC : 82599ES 10-Gigabit > > IO Virtualization: SR-IOV > > Command used: ./l2fwd -c 3 -w :02:00.1 -w :02:00.0 -- -p 3 -T 1 > > > Note: > > - Both the ports are in same NUMA node. I got the same results with full > CPU core as well as hyper-theraded core. > > - PCIe speed is same for both the ports. Attached the lspci and other > relevant output. > > - In multiple port case, each core was receiving only 11.8Mpps. This means > that RX is the bottleneck. > > > Questions: > > 1) For two ports case, I am getting only 11.8Mpps per port compared to > single port case, for which I got line rate. What could be the reason for > this performance degradation? I was looking at the DPDK mail archive and > found the following article similar to this and couldn?t conclude anything. > > http://dpdk.org/ml/archives/dev/2013-May/000115.html > > > 2) Did anybody try this kind of performance test for i40E NIC? > > > Thanks, > > Swamy >
[dpdk-dev] [PKTGEN] additional terminal IO question
Keith, For the record, on my end (can only speak for myself) this is not a real problem. I work around it by using a different theme and live with it happily ever after. I just provided the input since I encountered it. /Arnon On Thu, Jan 21, 2016 at 5:27 PM, Wiles, Keith wrote: > > From: Arnon Warshavsky mailto:arnon at qwilt.com>> > Date: Thursday, January 21, 2016 at 9:04 AM > To: "Keith Wiles (Intel)" keith.wiles at intel.com>> > Cc: Matthew Hall mailto:mhall at mhcomputing.net>>, > " > dev at dpdk.org<mailto:dev at dpdk.org>" mailto:dev at > dpdk.org>> > Subject: Re: [dpdk-dev] [PKTGEN] additional terminal IO question > > Keith, > On my end I'm ending with black on black with Konsole 2.3.3 on Centos 6.5 > starting as green on black. > > I changed my console to green on black and got the same results. When I > quit Pktgen the cursor color and text return to green. I can not set the > cursor color different from the text color on this terminal. This maybe a > problem with kconsole. Using xterm the cursor and text are restored as well. > > I would need to install a Centos 6.5 with Konsole. I can run konsole, but > the setting will not allow me to adjust the colors most likely it needs > more then just konsole installed with this MATE window system. Even in this > default state of black on white the cursor returns as black with black > text, which could be the problem??? > > > On Thu, Jan 21, 2016 at 4:55 PM, Wiles, Keith <mailto:keith.wiles at intel.com>> wrote: > On 1/20/16, 11:53 PM, "dev on behalf of Matthew Hall" < > dev-bounces at dpdk.org<mailto:dev-bounces at dpdk.org> on behalf of > mhall at mhcomputing.net<mailto:mhall at mhcomputing.net>> wrote: > > >If I try using pktgen theme mode (-T) or unmodified, without commenting > >out some of the stuff I mentioned I disabled for debugging in the > >previous thread, it seems like it sets the pktgen prompt to be invisible > >(black text on black??? or I'm not sure just want) on my TTY which has a > >black background. > > I am not sure what you changed for debugging, but on my Ubuntu 15.10 using > MATE Terminal 1.10.1 with a black background and white text the cursor > remains as white after I quit Pktgen. If you have a crash for some reason > the cmdline code leaves the TTY in a raw mode no echo, which is just like > no cursor. I have to also do ?stty sane? to get echo/cursor back on. Is > this what is happing to you? > > I created a white-black.theme I was using and did not try to make it > pretty as I use a black on light yellow background. Here is the theme. > theme default white none off > theme top.spinner cyan none bold > theme top.ports green none bold > theme top.page white none off > theme top.copyright yellow none off > theme top.poweredby blue none bold > theme sep.dash blue none off > theme sep.text white none off > theme stats.port.label blue none bold > theme stats.port.flags blue none bold > theme stats.port.status green none bold > theme stats.dyn.label yellow none off > theme stats.dyn.values yellow none off > theme stats.stat.label magenta none off > theme stats.stat.values white none off > theme stats.total.label red none bold > theme stats.colon blue none bold > theme pktgen.prompt green none off > cls > > Please give more details next time to help me understand the problem like > OS type, terminal type used, versions, ? > > > Thanks > ++Keith > > > >If you quit the app it does not reset the colors so my shell is also > >invisible, until I blindly run the reset command. > > > >Did anybody else try it on a black background? Did anybody else see > >these issues with it as well? > > > >Matthew. > > > > > Regards, > Keith > > > > > > > > -- > > Arnon Warshavsky > Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com > <mailto:arnon at qwilt.com> > -- *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com *
[dpdk-dev] [PKTGEN] additional terminal IO question
Keith, On my end I'm ending with black on black with Konsole 2.3.3 on Centos 6.5 starting as green on black. On Thu, Jan 21, 2016 at 4:55 PM, Wiles, Keith wrote: > On 1/20/16, 11:53 PM, "dev on behalf of Matthew Hall" < > dev-bounces at dpdk.org on behalf of mhall at mhcomputing.net> wrote: > > >If I try using pktgen theme mode (-T) or unmodified, without commenting > >out some of the stuff I mentioned I disabled for debugging in the > >previous thread, it seems like it sets the pktgen prompt to be invisible > >(black text on black??? or I'm not sure just want) on my TTY which has a > >black background. > > I am not sure what you changed for debugging, but on my Ubuntu 15.10 using > MATE Terminal 1.10.1 with a black background and white text the cursor > remains as white after I quit Pktgen. If you have a crash for some reason > the cmdline code leaves the TTY in a raw mode no echo, which is just like > no cursor. I have to also do ?stty sane? to get echo/cursor back on. Is > this what is happing to you? > > I created a white-black.theme I was using and did not try to make it > pretty as I use a black on light yellow background. Here is the theme. > theme default white none off > theme top.spinner cyan none bold > theme top.ports green none bold > theme top.page white none off > theme top.copyright yellow none off > theme top.poweredby blue none bold > theme sep.dash blue none off > theme sep.text white none off > theme stats.port.label blue none bold > theme stats.port.flags blue none bold > theme stats.port.status green none bold > theme stats.dyn.label yellow none off > theme stats.dyn.values yellow none off > theme stats.stat.label magenta none off > theme stats.stat.values white none off > theme stats.total.label red none bold > theme stats.colon blue none bold > theme pktgen.prompt green none off > cls > > Please give more details next time to help me understand the problem like > OS type, terminal type used, versions, ? > > > Thanks > ++Keith > > > >If you quit the app it does not reset the colors so my shell is also > >invisible, until I blindly run the reset command. > > > >Did anybody else try it on a black background? Did anybody else see > >these issues with it as well? > > > >Matthew. > > > > > Regards, > Keith > > > > > -- *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com *
[dpdk-dev] [PKTGEN] additional terminal IO question
Black background gets me to the blind reset as well. Pktgen is the only tab I keep with non black background.. On Thu, Jan 21, 2016 at 7:53 AM, Matthew Hall wrote: > If I try using pktgen theme mode (-T) or unmodified, without commenting > out some of the stuff I mentioned I disabled for debugging in the previous > thread, it seems like it sets the pktgen prompt to be invisible (black text > on black??? or I'm not sure just want) on my TTY which has a black > background. > > If you quit the app it does not reset the colors so my shell is also > invisible, until I blindly run the reset command. > > Did anybody else try it on a black background? Did anybody else see these > issues with it as well? > > Matthew. > -- *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com *
[dpdk-dev] tcpdump support in DPDK 2.3
> of > the multi-process infrastructure in DPDK. A secondary process can attach > to a > primary at runtime and provide the packet filtering and dumping > capability. > * ideally we want to create a generic packet mirroring callback inside the > EAL, > that can be set up to mirror packets going through Rx/Tx on an ethdev. > * using this, packets being received on the port to be monitored are sent > via > an rte_ring (ring ethdev) to the secondary process which takes those > packets > and does any filtering on them. [This would be where BPF could fit into > things, but it's not something we have looked at yet.] > * initially we plan to have the secondary process then write packets to a > pcap > file using a pcap PMD, but down the road if we get other PMDs, like a > KNI PMD > or a TAP device PMD, those could be used as targets instead. > > This implementation we hope should provide enough hooks to enable the > standard > tools to be used for monitoring and capturing packets. We will send out > draft > implementation code for various parts of this as soon as we have it. > > Additional feedback welcome, as always. :-) > > Regards, > /Bruce > > -- *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com *
[dpdk-dev] releases scheduling
+1 for Ubuntu version numbering On Tue, Dec 15, 2015 at 3:37 PM, O'Driscoll, Tim wrote: > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > Sent: Sunday, December 13, 2015 7:23 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] releases scheduling > > > > Hi all, > > > > We need to define the deadlines for the next releases. > > During 2015, we were doing a release every 4 months. > > If we keep the same pace, the next releases would be: > > 2.3: end of March > > 2.4: end of July > > 2.5: end of November > > > > However, things move fast and it may be a bit long to wait 4 months for > > a feature. That's why I suggest to progressively shorten release terms: > > 2.3: end of March > > 2.4: mid July > > 2.5: end of October > > and continue with a release every 3 months: > > 2.6: end of January > > 2.7: end of April > > 2.8: end of July > > This planning would preserve some of the major holiday periods > > (February, May, August, December). > > > > The first period, for the first submission of a feature, was 2 months > > long. > > Then we had 2 other months to discuss, merge and fix. > > We should shorten only the first period. > > > > Anyway, the next deadlines should be unchanged: > > - January 31: end of first submission phase > > - March 31: release 2.3 > > > > Opinions are welcome. > > I think moving to quarterly releases is a good idea. Your proposal to do > this in a gradual way, so that we don't change the 2.3 dates, also makes > sense. > > Should we consider changing the release numbering at the same time? It's > difficult to keep track of when each 2.x release is due, and we don't have > any criteria in place for moving to 3.x in future. Many people like the > Ubuntu numbering scheme of Year.Month. Should we consider adopting that > convention? If we move in future to a model where we have long-term support > releases (something that was touched on in Dublin), then we could append an > LTS designation to the release number. > > > Tim > -- *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com *
[dpdk-dev] Reshuffling of rte_mbuf structure.
If NO_TX_OFFLOAD only changes the layout in terms of relative field
location in cache lines, and does not eliminate the fields themselves
why should the using code be affected?
On Mon, Nov 2, 2015 at 8:30 PM, shesha Sreenivasamurthy (shesha) <
shesha at cisco.com> wrote:
> One issue I see with optimization config options such as NO_TX_OFFLOAD,
> NO_MULTISEG, NO_REFCOUNT is: It is not sufficient to have those ?Ifdefs?
> inside mbuf structure, but should be sprinkled all over the code where
> corresponding fields are used. This may make the code messier.
>
> --
> *- Thanks*
> *char * (*shesha) (uint64_t cache, uint8_t F00D)*
> *{ return 0xC0DE; } *
>
> From: Stephen Hemminger
> Date: Monday, November 2, 2015 at 8:24 AM
> To: Arnon Warshavsky
> Cc: Cisco Employee , "dev at dpdk.org"
> Subject: Re: [dpdk-dev] Reshuffling of rte_mbuf structure.
>
> On Sun, 1 Nov 2015 06:45:31 +0200
> Arnon Warshavsky wrote:
>
> My 2 cents,
> This was brought up in the recent user space summit, and it seems that
> indeed there is no one cache lines arrangement that fits all.
> OTOH multiple compile time options to suffice all flavors, would make it
> unpleasant to read maintain test and debug.
> (I think there was quiet a consensus in favor of reducing compile options
> in general)
> Currently I manage similar deviations via our own source control which I
> admit to be quite a pain.
> I would prefer an option of code manipulation/generation by some script
> during dpdk install,
> which takes the default version of rte_mbuf.h,
> along with an optional user file (json,xml,elvish,whatever) defining the
> structure replacements,
> creating your custom version, and placing it instead of the installed copy
> of rte_mbuf.h.
> Maybe the only facility required from dpdk is just the ability to register
> calls to such user scripts at some install stage(s), providing the mean
> along with responsibility to the user.
> /Arnon
> On Sat, Oct 31, 2015 at 6:44 AM, shesha Sreenivasamurthy (shesha) <
> shesha at cisco.com> wrote:
> > In Cisco, we are using DPDK for a very high speed packet processor
> > application. We don't use NIC TCP offload / RSS hashing. Putting those
> > fields in the first cache-line - and the obligatory mb->next datum in the
> > second cache line - causes significant LSU pressure and performance
> > degradation. If it does not affect other applications, I would like to
> > propose reshuffling of fields so that the obligator "next" field falls in
> > first cache line and RSS hashing goes to next. If this re-shuffling
> indeed
> > hurts other applications, another idea is to make it compile time
> > configurable. Please provide feedback.
> >
> > --
> > - Thanks
> > char * (*shesha) (uint64_t cache, uint8_t F00D)
> > { return 0xC0DE; }
> >
>
>
> Having different layouts will be a disaster for distro's they have to
> choose one.
> And I hate to introduce more configuration!
>
> But we see the same issue. It would make sense if there were configuration
> options
> for some common optimizations NO_TX_OFFLOAD, NO_MULTISEG, NO_REFCOUNT and
> then
> the mbuf got optimized for those combinations. Seems better than config
> options
> like LAYOUT1, LAYOUT2, ...
>
> In this specific case, I think lots of driver could be check nb_segs == 1
> and avoiding
> the next field for simple packets.
>
> Long term, I think this will be losing battle. As DPDK grows more
> features, the current
> mbuf structure will grow there is really nothing stopping the bloat of
> meta data.
>
>
--
*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
*
[dpdk-dev] Reshuffling of rte_mbuf structure.
My 2 cents,
This was brought up in the recent user space summit, and it seems that
indeed there is no one cache lines arrangement that fits all.
OTOH multiple compile time options to suffice all flavors, would make it
unpleasant to read maintain test and debug.
(I think there was quiet a consensus in favor of reducing compile options
in general)
Currently I manage similar deviations via our own source control which I
admit to be quite a pain.
I would prefer an option of code manipulation/generation by some script
during dpdk install,
which takes the default version of rte_mbuf.h,
along with an optional user file (json,xml,elvish,whatever) defining the
structure replacements,
creating your custom version, and placing it instead of the installed copy
of rte_mbuf.h.
Maybe the only facility required from dpdk is just the ability to register
calls to such user scripts at some install stage(s), providing the mean
along with responsibility to the user.
/Arnon
On Sat, Oct 31, 2015 at 6:44 AM, shesha Sreenivasamurthy (shesha) <
shesha at cisco.com> wrote:
> In Cisco, we are using DPDK for a very high speed packet processor
> application. We don't use NIC TCP offload / RSS hashing. Putting those
> fields in the first cache-line - and the obligatory mb->next datum in the
> second cache line - causes significant LSU pressure and performance
> degradation. If it does not affect other applications, I would like to
> propose reshuffling of fields so that the obligator "next" field falls in
> first cache line and RSS hashing goes to next. If this re-shuffling indeed
> hurts other applications, another idea is to make it compile time
> configurable. Please provide feedback.
>
> --
> - Thanks
> char * (*shesha) (uint64_t cache, uint8_t F00D)
> { return 0xC0DE; }
>
--
*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
*
[dpdk-dev] i40e: problem with rx packet drops not accounted in statistics
;> PMD: i40e_dev_stats_get(): priority_xon_2_xoff[1]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xon_tx[2]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xoff_tx[2]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xon_2_xoff[2]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xon_tx[3]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xoff_tx[3]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xon_2_xoff[3]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xon_tx[4]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xoff_tx[4]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xon_2_xoff[4]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xon_tx[5]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xoff_tx[5]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xon_2_xoff[5]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xon_tx[6]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xoff_tx[6]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xon_2_xoff[6]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xon_tx[7]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xoff_tx[7]: 0 > > >>>> PMD: i40e_dev_stats_get(): priority_xon_2_xoff[7]: 0 > > >>>> PMD: i40e_dev_stats_get(): rx_size_64: 0 > > >>>> PMD: i40e_dev_stats_get(): rx_size_127: 0 > > >>>> PMD: i40e_dev_stats_get(): rx_size_255: 0 > > >>>> PMD: i40e_dev_stats_get(): rx_size_511: 0 > > >>>> PMD: i40e_dev_stats_get(): rx_size_1023: 0 > > >>>> PMD: i40e_dev_stats_get(): rx_size_1522: 16779 > > >>>> PMD: i40e_dev_stats_get(): rx_size_big: 0 > > >>>> PMD: i40e_dev_stats_get(): rx_undersize: 0 > > >>>> PMD: i40e_dev_stats_get(): rx_fragments: 0 > > >>>> PMD: i40e_dev_stats_get(): rx_oversize: 0 > > >>>> PMD: i40e_dev_stats_get(): rx_jabber:0 > > >>>> PMD: i40e_dev_stats_get(): tx_size_64: 0 > > >>>> PMD: i40e_dev_stats_get(): tx_size_127: 0 > > >>>> PMD: i40e_dev_stats_get(): tx_size_255: 0 > > >>>> PMD: i40e_dev_stats_get(): tx_size_511: 0 > > >>>> PMD: i40e_dev_stats_get(): tx_size_1023: 0 > > >>>> PMD: i40e_dev_stats_get(): tx_size_1522: 0 > > >>>> PMD: i40e_dev_stats_get(): tx_size_big: 0 > > >>>> PMD: i40e_dev_stats_get(): mac_short_packet_dropped: 0 > > >>>> PMD: i40e_dev_stats_get(): checksum_error: 0 > > >>>> PMD: i40e_dev_stats_get(): fdir_match: 0 > > >>>> PMD: i40e_dev_stats_get(): * PF stats end > > >>>> > > >>>> ... > > >>>> > > >>>> The count for rx_unicast is exactly the number of packets we would > > >>>> have expected and the count for rx_discards in the VSI stats is > > >>>> exactly the number of packets we are missing. > > >>>> The question is why this number shows up only in the VSI stats and > > >>>> not in the PF stats and of course why the packets which were > > >>>> obviously discarded are still counted in the rx_unicast stats. > > >>>> This test was performed using DPDK 2.1 and the firmware of the > > >>>> XL710 is the latest one (FW 4.40 API 1.4 NVM 04.05.03). > > >>>> Do you have an idea what might be going on? > > >>>> > > >>>> Best regards, > > >>>> Martin > > >>>> > > >>>> > > > > -- *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com *
[dpdk-dev] Inconsistent statistics counters for pmd_i40e
Hi Eimar I had to build i40e driver from latest source , unload the one that came with my machine, load the one I built and only then I managed to get the "update available" when running the nvmupdate app. Machine was up from boot without running dpdk stuff (i.e no nic unbinding and such) prior to running the update app. Oddly enough, it updated my fw to from 4.23 only to 4.33, and after another reboot and another run it got from 4.33 to 4.4. After that it reported that the fw is up to date. After all that - still no drop counters when packets are dropped... /Arnon On Thu, Oct 22, 2015 at 3:48 PM, Eimear Morrissey < eimear.morrissey at ie.ibm.com> wrote: > Arnon Warshavsky wrote on 10/22/2015 12:12:47 PM: > > > From: Arnon Warshavsky > > To: Eimear Morrissey/Ireland/IBM at IBMIE > > Cc: dev at dpdk.org > > Date: 10/22/2015 12:12 PM > > > Subject: Re: [dpdk-dev] Inconsistent statistics counters for pmd_i40e > > > > You are right. > > Given this thread updated today > > http://dpdk.org/ml/archives/dev/2015-September/023480.html (updates > > from today still not there) > > It seems I was too quick to jump to conclusion. > > > Just in case, when bound to i40e, can you run ethtool -i on that > interface? > > It should show the fw version. > > > thanks > > /Arnon > > > > On Thu, Oct 22, 2015 at 12:57 PM, Eimear Morrissey < > > eimear.morrissey at ie.ibm.com> wrote: > > Arnon Warshavsky wrote on 10/19/2015 03:46:22 PM: > > > > > From: Arnon Warshavsky > > > To: Eimear Morrissey/Ireland/IBM at IBMIE > > > Cc: dev at dpdk.org > > > Date: 10/19/2015 03:46 PM > > > > > Subject: Re: [dpdk-dev] Inconsistent statistics counters for pmd_i40e > > > > > > Hi Eimear > > > > > > This is the link I have. > > > https://downloadcenter.intel.com/download/24769 > > > > > > I guess that the version seen in the web page comes from a different > > > parallel universe. > > > You should see the actual fw version inside the zip file. > > > > > Thanks > > > /Arnon > > > > > > On Mon, Oct 19, 2015 at 5:30 PM, Eimear Morrissey < > > eimear.morrissey at ie.ibm.com > > > > wrote: > > > Arnon Warshavsky wrote on 10/19/2015 03:01:46 PM: > > > > > > > From: Arnon Warshavsky > > > > To: Eimear Morrissey/Ireland/IBM at IBMIE > > > > Cc: dev at dpdk.org > > > > Date: 10/19/2015 03:01 PM > > > > Subject: Re: [dpdk-dev] Inconsistent statistics counters for pmd_i40e > > > > > > > > > > > Hi Eimear, > > > > > > > > I just experienced the same problem with firmware versions 4.23 and > > > > 4.33 (dpdk 2.0). Did not get to try the latest which is 4.5. > > > > Looking at the code, I don't see that this counter is being read any > > > > differently than its peer counters and I suspect the nic itself. > > > > Can you tell which firmware version you were using? > > > > > > > > thanks > > > > /Arnon > > > > > > > > On Mon, Oct 19, 2015 at 2:43 PM, Eimear Morrissey < > > > eimear.morrissey at ie.ibm.com > > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > I'm having issues measuring packets dropped at the NIC in both the > 2.0.0 > > > > and 2.1.0 versions of DPDK on an X710 Intel NIC. > > > > > > > > In dpdk-2.0.0 > > > > Using rte_eth_xstats the rx_packets and rx_bytes counters increase as > > > > expected, however rx_missed_errors is always 0 even if a sleep > > statement is > > > > added between calls to rte_eth_rx_burst. However changing the > coremask so > > > > the application is running on a different socket than the card will > cause > > > > rx_missed_errors to increment for a limited amount of time and then > stop. > > > > Using rte_eth_stats, ipackets is incremented on packet receipt but > the > > > > q_ipackets and q_errors arrays remain zero. Even crossing sockets > seems to > > > > have no effect on q_errors. > > > > > > > > In dpdk-2.1.0 the behaviour is the same as above, except that > > the number of > > > > fields returned by rte_eth_xstats_get is reduced (no rx_missed > errors at > > > > all) so running on a different socket no longer has any noticeable > effect > > > > on the stats. > > > > > > >
[dpdk-dev] Inconsistent statistics counters for pmd_i40e
You are right. Given this thread updated today http://dpdk.org/ml/archives/dev/2015-September/023480.html (updates from today still not there) It seems I was too quick to jump to conclusion. Just in case, when bound to i40e, can you run ethtool -i on that interface? It should show the fw version. thanks /Arnon On Thu, Oct 22, 2015 at 12:57 PM, Eimear Morrissey < eimear.morrissey at ie.ibm.com> wrote: > Arnon Warshavsky wrote on 10/19/2015 03:46:22 PM: > > > From: Arnon Warshavsky > > To: Eimear Morrissey/Ireland/IBM at IBMIE > > Cc: dev at dpdk.org > > Date: 10/19/2015 03:46 PM > > > Subject: Re: [dpdk-dev] Inconsistent statistics counters for pmd_i40e > > > > Hi Eimear > > > > This is the link I have. > > https://downloadcenter.intel.com/download/24769 > > > > I guess that the version seen in the web page comes from a different > > parallel universe. > > You should see the actual fw version inside the zip file. > > > Thanks > > /Arnon > > > > On Mon, Oct 19, 2015 at 5:30 PM, Eimear Morrissey < > eimear.morrissey at ie.ibm.com > > > wrote: > > Arnon Warshavsky wrote on 10/19/2015 03:01:46 PM: > > > > > From: Arnon Warshavsky > > > To: Eimear Morrissey/Ireland/IBM at IBMIE > > > Cc: dev at dpdk.org > > > Date: 10/19/2015 03:01 PM > > > Subject: Re: [dpdk-dev] Inconsistent statistics counters for pmd_i40e > > > > > > > > Hi Eimear, > > > > > > I just experienced the same problem with firmware versions 4.23 and > > > 4.33 (dpdk 2.0). Did not get to try the latest which is 4.5. > > > Looking at the code, I don't see that this counter is being read any > > > differently than its peer counters and I suspect the nic itself. > > > Can you tell which firmware version you were using? > > > > > > thanks > > > /Arnon > > > > > > On Mon, Oct 19, 2015 at 2:43 PM, Eimear Morrissey < > > eimear.morrissey at ie.ibm.com > > > > wrote: > > > > > > > > > Hi, > > > > > > I'm having issues measuring packets dropped at the NIC in both the > 2.0.0 > > > and 2.1.0 versions of DPDK on an X710 Intel NIC. > > > > > > In dpdk-2.0.0 > > > Using rte_eth_xstats the rx_packets and rx_bytes counters increase as > > > expected, however rx_missed_errors is always 0 even if a sleep > statement is > > > added between calls to rte_eth_rx_burst. However changing the coremask > so > > > the application is running on a different socket than the card will > cause > > > rx_missed_errors to increment for a limited amount of time and then > stop. > > > Using rte_eth_stats, ipackets is incremented on packet receipt but the > > > q_ipackets and q_errors arrays remain zero. Even crossing sockets > seems to > > > have no effect on q_errors. > > > > > > In dpdk-2.1.0 the behaviour is the same as above, except that the > number of > > > fields returned by rte_eth_xstats_get is reduced (no rx_missed errors > at > > > all) so running on a different socket no longer has any noticeable > effect > > > on the stats. > > > > > > My understanding from the API manual is that the rte_eth_stats q_errors > > > array should count the packets missed because software isn't polling > fast > > > enough, but that doesn't seem to be the case? Is there a standard DPDK > way > > > to check this? The application is a forwarding one so there's no other > way > > > to estimate drop except through NIC rx. > > > > > > Thanks, > > > Eimear > > > > > > > > > > > > -- > > > > > > Arnon Warshavsky > > > Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | > arnon at qwilt.com > > > Hi Arnon, > > > > The firmware version I'm using is 4.26. Where do you see the latest > > is 4.5 - I can't find anything obvious in the download centre? > > > > Regards, > > Eimear > > > > > > > > -- > > > > Arnon Warshavsky > > Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | > arnon at qwilt.com > > > I tried installing the firmware but on running the NVM update tool I just > get "No updates available for your device" which makes me think that (for > my SKU at least) I'm on the latest firmware. > > Also, if I bind the card back to the i40e driver, I can force the dropped > count in ifconfig to increase by decreasing the rx ring size so I'm not > convinced it's entirely a hardware issue. > > Regards, > Eimear > > -- *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com *
[dpdk-dev] Inconsistent statistics counters for pmd_i40e
Hi Eimear This is the link I have. https://downloadcenter.intel.com/download/24769 I guess that the version seen in the web page comes from a different parallel universe. You should see the actual fw version inside the zip file. Thanks /Arnon On Mon, Oct 19, 2015 at 5:30 PM, Eimear Morrissey < eimear.morrissey at ie.ibm.com> wrote: > Arnon Warshavsky wrote on 10/19/2015 03:01:46 PM: > > > From: Arnon Warshavsky > > To: Eimear Morrissey/Ireland/IBM at IBMIE > > Cc: dev at dpdk.org > > Date: 10/19/2015 03:01 PM > > Subject: Re: [dpdk-dev] Inconsistent statistics counters for pmd_i40e > > > > > Hi Eimear, > > > > I just experienced the same problem with firmware versions 4.23 and > > 4.33 (dpdk 2.0). Did not get to try the latest which is 4.5. > > Looking at the code, I don't see that this counter is being read any > > differently than its peer counters and I suspect the nic itself. > > Can you tell which firmware version you were using? > > > > thanks > > /Arnon > > > > On Mon, Oct 19, 2015 at 2:43 PM, Eimear Morrissey < > eimear.morrissey at ie.ibm.com > > > wrote: > > > > > > Hi, > > > > I'm having issues measuring packets dropped at the NIC in both the 2.0.0 > > and 2.1.0 versions of DPDK on an X710 Intel NIC. > > > > In dpdk-2.0.0 > > Using rte_eth_xstats the rx_packets and rx_bytes counters increase as > > expected, however rx_missed_errors is always 0 even if a sleep statement > is > > added between calls to rte_eth_rx_burst. However changing the coremask so > > the application is running on a different socket than the card will cause > > rx_missed_errors to increment for a limited amount of time and then stop. > > Using rte_eth_stats, ipackets is incremented on packet receipt but the > > q_ipackets and q_errors arrays remain zero. Even crossing sockets seems > to > > have no effect on q_errors. > > > > In dpdk-2.1.0 the behaviour is the same as above, except that the number > of > > fields returned by rte_eth_xstats_get is reduced (no rx_missed errors at > > all) so running on a different socket no longer has any noticeable effect > > on the stats. > > > > My understanding from the API manual is that the rte_eth_stats q_errors > > array should count the packets missed because software isn't polling fast > > enough, but that doesn't seem to be the case? Is there a standard DPDK > way > > to check this? The application is a forwarding one so there's no other > way > > to estimate drop except through NIC rx. > > > > Thanks, > > Eimear > > > > > > > > -- > > > > Arnon Warshavsky > > Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | > arnon at qwilt.com > > Hi Arnon, > > The firmware version I'm using is 4.26. Where do you see the latest is 4.5 > - I can't find anything obvious in the download centre? > > Regards, > Eimear > > -- *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com *
[dpdk-dev] Inconsistent statistics counters for pmd_i40e
Hi Eimear, I just experienced the same problem with firmware versions 4.23 and 4.33 (dpdk 2.0). Did not get to try the latest which is 4.5. Looking at the code, I don't see that this counter is being read any differently than its peer counters and I suspect the nic itself. Can you tell which firmware version you were using? thanks /Arnon On Mon, Oct 19, 2015 at 2:43 PM, Eimear Morrissey < eimear.morrissey at ie.ibm.com> wrote: > > > Hi, > > I'm having issues measuring packets dropped at the NIC in both the 2.0.0 > and 2.1.0 versions of DPDK on an X710 Intel NIC. > > In dpdk-2.0.0 > Using rte_eth_xstats the rx_packets and rx_bytes counters increase as > expected, however rx_missed_errors is always 0 even if a sleep statement is > added between calls to rte_eth_rx_burst. However changing the coremask so > the application is running on a different socket than the card will cause > rx_missed_errors to increment for a limited amount of time and then stop. > Using rte_eth_stats, ipackets is incremented on packet receipt but the > q_ipackets and q_errors arrays remain zero. Even crossing sockets seems to > have no effect on q_errors. > > In dpdk-2.1.0 the behaviour is the same as above, except that the number of > fields returned by rte_eth_xstats_get is reduced (no rx_missed errors at > all) so running on a different socket no longer has any noticeable effect > on the stats. > > My understanding from the API manual is that the rte_eth_stats q_errors > array should count the packets missed because software isn't polling fast > enough, but that doesn't seem to be the case? Is there a standard DPDK way > to check this? The application is a forwarding one so there's no other way > to estimate drop except through NIC rx. > > Thanks, > Eimear > -- *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com *
[dpdk-dev] Missing prefetch in non-vector rx function
Hi All Moving from dpdk 1.5 to 2.0 we observed a PPS performance degradation of ~30%. After chasing this one for a while we found the problem: A) Between the 2 versions rte_mbuf was increased in size from 1 to 2 cache lines. B) The standard (non-vector) rx function does not perform a prefetch for the 2nd cache line of the mbuf (I see this bug exists in 2.1 as well) and it touches it setting the next pointer to NULL. I tested it in ixgbe, but it looks like it exists in all drivers in the *_rx_recv_pkts() and *_rx_recv_scattered_pkts() functions. Once added the prefetch for the 2nd line, we were back in our previous numbers. I believe this one slipped under the radar as the vector mode is now the default. We stumbled into it because we work in non-vector mode due to a different mempool bug in 2.0 which sometimes crashes the application upon port stop. I have 2 questions 1) Could anyone tell if the regression tests are comparing performance while building DPDK with the default set of flags alone, or are multiple options examined? 2) How are issues like that being tracked and later associated to a patch? Thanks /Arnon *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com *
