From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=PoMU9M4iFkeyeyd7ns3dVQvca9eFuDKL3brZErayFR4=; b=U4D2bFeExb/BtqGKD50PCDWHi5rZOZ7Bk51OwW1M4OOok3MtKCt7YGjMOy2ok5nNvt zIAljWr5Ac8l0PPBrBDYLUBHQfOtB8ls20Jyvn0kXlN1g1sMSRKBNiknbdPRUrPXTJ0C N7D5Bo3v9oaZgAQ+DEldmzSnMEY/wlnLxcfd9B+pRjiwFQaNXOdcaqg1xPfpJ8U304LG N59Ft0dlWjlanD7Xs6h82p/chEhgjSxiVJYw6YtEGF8xvFecPAATjQzeUn136zuB8EuE kEGB0qFPUNuGZTd1fLGJHphr0RPJyXcpOjB6Iwul+a/GSckCDM6l90w9e5dbuu5uUvbr PBGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=PoMU9M4iFkeyeyd7ns3dVQvca9eFuDKL3brZErayFR4=; b=Eul9mk1aOD1lxCOcRDIa2kEru7J7ZtqGuVxMIuxnmVsjXbvVgPgiRI09QHVYc34vBH WGFtIkwAOJ9/yCtml76LfwZ7TtocA/RPrLo0g8B+nW/Nn7M/nx71EM1H7MoNiw+C16sO w4ZpgjTDF6+fDGiznHdJfQ92Y8PyWAC1unFapYVIM+XMcbCSYE2IfQoxbdqR6QwCf9Qi JFhI3Yc2AM5zdI57weoDbuj6Got7HeC8CBuJ2rNgz1P79Sj7KIsgCW5gw1gwlTA+l+on MIM8AOhV/KahamWUsMbCIpc0t6kq78ntSthC8knunrdiOKglnnyCxz2cS757KgFX0ZcR PHgw== X-Gm-Message-State: AOPr4FVPJUhXHzskDogjLr0xUvbltlTQWAqZDHRAEaWYGr4okw5gJz2whWpMXo7cNUQJM3ch X-Received: by 10.194.10.162 with SMTP id j2mr23778348wjb.72.1461963484154; Fri, 29 Apr 2016 13:58:04 -0700 (PDT) Received: from [192.168.0.11] (was59-1-82-226-113-214.fbx.proxad.net. [82.226.113.214]) by smtp.gmail.com with ESMTPSA id gr4sm16469549wjd.23.2016.04.29.13.58.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2016 13:58:02 -0700 (PDT) To: Arnon Warshavsky , Jay Rolette References: <572352A3.6030400@6wind.com> Cc: Don Provan , "dev@dpdk.org" , "Zhang, Helin" , "Ananyev, Konstantin" , John Daley From: Olivier MATZ Message-ID: <5723CACD.40408@6wind.com> Date: Fri, 29 Apr 2016 22:57:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] removing mbuf error flags X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 20:58:04 -0000 Hi, On 04/29/2016 10:00 PM, Arnon Warshavsky wrote: > > > 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@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. 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