[dpdk-dev] Issue on rte_sched.c
Yes i am refereing on that commit. About RTE_MACHINE_CPUFLAG_* , i agreed. I never prepare a patch ... maybe is time to put my hands on that. 2016-04-13 20:35, Ariel Rodriguez: > Hello, viewing the new code of librte_sched/ i found this line strange ... > > #if defined(__SSE4__) Are you refering to http://dpdk.org/commit/90f455f ? > if instead i use : > > #if defined(__SSE4_2__) || defined(__SSE4_1__) > > works like a charm ... > > i never see in any directive like __SSE4__ Indeed, it is strange. By the way, it is recommended to use RTE_MACHINE_CPUFLAG_*.
[dpdk-dev] removing mbuf error flags
>From: Olivier MATZ [mailto:olivier.matz at 6wind.com] >Sent: Friday, April 29, 2016 1:58 PM > >The point is today it's broken, and no application running on top of DPDK >check these flags because they are set to 0. If we decide to assign a value >to these flags, it will break the working applications because they don't >expect to receive invalid packets. Maybe a proper solution would be to >enable these flags on demand in PMD configuration, and add a feature >flag for this feature. It's not broken, it just doesn't do anything. Yes, such a feature *has* to be explicitly requested by the application. By default, broken packets should not be delivered. >I think we should not keep things half-done too long. It's confusing and >useless as-is. Fine with me. I don't see how it's confusing, but, from what you're saying, it is clearly useless. The only reason to keep it would be that if such a feature is added in the future, it could be added without changing the mbuf structure, but I don't know whether that's important. -don provan dprovan at bivio.net
[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.
