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 24656C37C for ; Thu, 9 Jun 2016 12:37:59 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id n184so218975342wmn.1 for ; Thu, 09 Jun 2016 03:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=gbrjLysoCcpFFgm+DjIN6NcejKJbi2VoOT/wxOTl4X8=; b=Qyv2aY/1Hs4HHGNxBZSCr9rhF+EW++5Im8E3DjKEp+55WEfIjB3sJFneod4LQweIEM R8ocnGRrOqCluZcGrvWndY+OSPgalbORTl4jtYNj79ZIBD+cUMj9GDJnz9u0sHgxbPzW Zn/P+V0Kh8AUD7294Is2OszuDm8rgdEhWB0juXwyFTno60MBhNa377eSptpUFjRDhL61 4iRIM7Ge3OHpicIG7qzce4AHeYz0yens+72f/4sfG8meKrqS4Lg6ST4RPJ7C+NY/6pdT dGoQddD3ihGJi8lCjisJIrySF4v/io84qQAFAHAq6IV3ajOtHEYzz4l98KjlZkiJviOY ZGLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=gbrjLysoCcpFFgm+DjIN6NcejKJbi2VoOT/wxOTl4X8=; b=K7C0v3BhdAqo8eD1avQLpxACMiJPVeQ63TJfuYhP6V2KlyjiGp+avdsfm08p061Z+9 Zy1ZC/f5KDvs6YHW0260xm9onpocBvn3zAogLhBV+x3qyMolThAXcb4gKpCL3MwLWBEr biUZNtCtaOx3HetIeFNt69d2/0cNf/zlcxUxlbuC/66k/fZz9JFTIgIVCDpoy52XmQY+ 0r7Fo0ymdvkMIekIvDZDhlyO1tyK7wuJkIGdiqoSBMrrAwbSRMwvcuIHv5pJQDeKy7zF OAcKE7ucT47nGT4kfGAvRUommw8KEifeYXBrPNHNYi1qS7ixCfHPl40wVYgXYbSHyCq0 sokg== X-Gm-Message-State: ALyK8tKkgZrcsADAYg4JPeVy2kbOI53BU7OdUfK8jpmEDxgGJWEhifbBYDpiTCj6098pj8KA X-Received: by 10.194.123.170 with SMTP id mb10mr8843332wjb.39.1465468678522; Thu, 09 Jun 2016 03:37:58 -0700 (PDT) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id u64sm6948775wmd.8.2016.06.09.03.37.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2016 03:37:57 -0700 (PDT) Date: Thu, 9 Jun 2016 12:37:54 +0200 From: Adrien Mazarguil To: Olivier Matz Cc: "Ananyev, Konstantin" , "dev@dpdk.org" , "Tan, Jianfeng" Message-ID: <20160609103754.GQ7621@6wind.com> Mail-Followup-To: Olivier Matz , "Ananyev, Konstantin" , "dev@dpdk.org" , "Tan, Jianfeng" References: <57237A88.6030807@6wind.com> <2601191342CEEE43887BDE71AB97725836B43013@irsmsx105.ger.corp.intel.com> <57592168.2020702@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57592168.2020702@6wind.com> Subject: Re: [dpdk-dev] supported packet types 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: Thu, 09 Jun 2016 10:37:59 -0000 On Thu, Jun 09, 2016 at 09:57:28AM +0200, Olivier Matz wrote: > Hi Konstantin, > > On 04/29/2016 06:03 PM, Ananyev, Konstantin wrote: > >> The following commit introduces a function to list the supported > >> packet types of a device: > >> > >> http://dpdk.org/browse/dpdk/commit/?id=78a38edf66 > >> > >> I would like to know what does "supported" precisely mean. > >> Is it: > >> > >> 1/ - if a ptype is marked as supported, the driver MUST set > >> this ptype if the packet matches the format described in rte_mbuf.h > >> > >> -> if the ptype is not recognized, the application is sure > >> that the packet is not one of the supported ptype > >> -> but this is difficult to take advantage of this inside an > >> application that supports several different ports model > >> that do not support the same packet types > >> > >> 2/ - if a ptype is marked as supported, the driver CAN set > >> the ptype if the packet matches the format described in rte_mbuf.h > >> > >> -> if a ptype is not recognized, the application does a software > >> fallback > >> -> in this case, it would useless to have the get_supported_ptype() > >> > >> Can you confirm if the PMDs and l3fwd (the only user) expect 1/ > >> or 2/ ? > > > > 1) > > > >> > >> Can you elaborate on the advantages of having this API? > > > > Application can rely on information provided by PMD avoid parsing packet manually to recognise it's pytpe. > > > >> > >> And a supplementary question: if a ptype is not marked as supported, > >> is it forbidden for a driver to set this ptype anyway? > > > > I suppose it is not forbidden, but there is no guarantee from PMD that it > > would be able to recognise that ptype. > > > > Konstantin > > > >> Because we can > >> imagine a hardware that can only recognize packets in some conditions > >> (ex: can recognize IPv4 if there is no vlan). > >> > >> I think properly defining the meaning of "supported" is mandatory > >> to have an application beeing able to use this feature, and avoid > >> PMDs to behave differently because the API is unclear (like we've > >> already seen for other features). > > Back on this. I've made some tests with ixgbe, and I'm afraid it > will be difficult to ensure that when a ptype is advertised, it will > always be set in the mbuf, whatever the layers below. Here are some > examples: > > - double vlans > > Ether(type=0x88A8)/Dot1Q(vlan=0x666)/Dot1Q(vlan=0x666)/IP()/UDP()/Raw("x"*32) > ixgbe advertises RTE_PTYPE_ETHER in supported ptypes > returned ptype: RTE_PTYPE_UNKNOWN > should be: L2_ETHER > (this works with any unknown ethtype) > > - ip6 in ip6 tunnel > ixgbe advertises RTE_PTYPE_TUNNEL_IP in supported ptypes > Ether()/IPv6()/IPv6()/UDP()/Raw("x"*32) > returned ptype: L2_ETHER L3_IPV6 > should be: L2_ETHER L3_IPV6 TUNNEL_IP INNER_L3_IPV6 INNER_L4_UDP > > - ip options > Ether()/IP(options=IPOption('\x83\x03\x10'))/UDP()/Raw("x"*32) > returned ptype: RTE_PTYPE_UNKNOWN > should be: L2_ETHER L3_IPV4_EXT L4_UDP > > - ip inside ip with options > Ether()/IP(options=IPOption('\x83\x03\x10'))/IP()/UDP()/Raw("x"*32) > returned ptype: L2_ETHER L3_IPV4_EXT > should be: L2_ETHER L3_IPV4_EXT TUNNEL_IP INNER_L3_IPV4 INNER_L4_UDP > > I'm sure we can find more examples that do not return the expected > result, knowing that ixgbe is probably one of the most complete > driver in dpdk. I'm afraid of the behavior for other PMDs :) AFAIK, mlx4/mlx5 have similar issues, while they have no problem identifying Dot1Q payloads, QinQ is another matter. For supported tunnel types such as VXLAN, non-standard UDP ports prevent them from being identified as such unless HW is configured properly (and then packets that use the standard UDP port are not recognized anymore). So yes, this API identifies what can be at best reported by PMDs in the right context assuming all conditions are met, and PMDs do not implement software fallbacks for obvious reasons. > That's why I think the get_supported_ptypes() function, as of today, > is useless for an application. I suggest instead to set the ptype > in an opportunistic fashion instead: > - if the driver/hw knows the ptype, set it > - else, set it to unknown > > What do you think? Makes sense to me, supported encapsulations cannot be described easily with the ptype API, applications cannot rely on it more than to get a rough idea of what flags may potentially be set sometimes in received mbufs, which is fine but not very useful. That suggestion is also in line with the recent RX checksum discussion [1], where basically HW not reporting something about a packet does not mean it is the opposite. [1] http://dpdk.org/ml/archives/dev/2016-May/039920.html > By the way, I'm working on a software implementation that return a > packet_type from a mbuf. I may need it for virtio offload, but before > that, I think it could be useful for debug purposes. I'll submit a > patchset for this in the coming days. > > Regards, > Olivier > > PS: sorry, many questions to you these days... answer when you have > the time ;) -- Adrien Mazarguil 6WIND