From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 2E717BE7C for ; Thu, 9 Jun 2016 09:57:35 +0200 (CEST) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bAusa-0001wl-3O; Thu, 09 Jun 2016 09:59:52 +0200 To: "Ananyev, Konstantin" References: <57237A88.6030807@6wind.com> <2601191342CEEE43887BDE71AB97725836B43013@irsmsx105.ger.corp.intel.com> Cc: "dev@dpdk.org" , "Tan, Jianfeng" , Adrien Mazarguil From: Olivier Matz Message-ID: <57592168.2020702@6wind.com> Date: Thu, 9 Jun 2016 09:57:28 +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: <2601191342CEEE43887BDE71AB97725836B43013@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 07:57:35 -0000 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 :) 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? 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 ;)