From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: removing mbuf error flags Date: Fri, 29 Apr 2016 22:57:49 +0200 Message-ID: <5723CACD.40408@6wind.com> References: <572352A3.6030400@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Don Provan , "dev@dpdk.org" , "Zhang, Helin" , "Ananyev, Konstantin" , John Daley To: Arnon Warshavsky , Jay Rolette Return-path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id 601AB2BC3 for ; Fri, 29 Apr 2016 22:58:04 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id g17so54780968wme.1 for ; Fri, 29 Apr 2016 13:58:04 -0700 (PDT) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi, On 04/29/2016 10:00 PM, Arnon Warshavsky wrote: >=20 >=20 > On Fri, Apr 29, 2016 at 9:24 PM, Jay Rolette > wrote: >=20 > On Fri, Apr 29, 2016 at 1:16 PM, Don Provan > wrote: >=20 > > >From: Olivier Matz [mailto:olivier.matz@6wind.com ] > > >Subject: [dpdk-dev] removing mbuf error flags > > > > > >My opinion is that invalid packets should not be given to the ap= plication > > 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, concept= ually, > > some applications would want to ask for bad packets because they = are > > specifically designed to handle various networking problems inclu= ding those > > that result in bad packets that the application can look at and r= eport. > > Furthermore, it makes technical sense for DPDK to support such ap= plications. > > > > Having said that, I have no idea if that's why that field was add= ed, and I > > don=E2=80=99t myself care if DPDK provides that feature in the fu= ture. I just > > thought I'd put the idea out there in case it makes any differenc= e 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 fea= ture in > > one driver or another. > > >=20 > Yep. Pretty much any networking security product needs to see malfo= rmed > packets. >=20 > Jay >=20 >=20 > +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 t= o > let the application capture malformed/unexpected packets was very helpf= ul. 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. I think we should not keep things half-done too long. It's confusing and useless as-is. If some applications really need to see these malformed packets, the API has to define in which conditions these flags are set and what is expected in the mbuf data when one of these flags is set. The only documentation we have now is: PKT_RX_OVERSIZE: Num of desc of an RX pkt oversize. PKT_RX_HBUF_OVERFLOW: Header buffer overflow. PKT_RX_RECIP_ERR: Hardware processing error. PKT_RX_MAC_ERR: MAC error. If it's not better defined, I don't know how an application could use these flags. Also, the PMDs should not behave differently by default. If someone commit on working on this in the comming weeks, I'll be happy to help, else I still think the current state has to be reverted. Regards, Olivier