From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f195.google.com (mail-wr0-f195.google.com [209.85.128.195]) by dpdk.org (Postfix) with ESMTP id A2D32AA97 for ; Tue, 17 Apr 2018 11:09:15 +0200 (CEST) Received: by mail-wr0-f195.google.com with SMTP id v60so29449746wrc.7 for ; Tue, 17 Apr 2018 02:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=BNNALLtybm0oJKMVXxpLjewVCS4pX4JxD6oyP7RFsuk=; b=SfnZJq6bbIZCUykTJE+93e9ZS9QWE4Ve87D/8dMPR1+FSD77lUkPS3PrnKNzNDNkS/ aqULAYhj/mCqkt9u13uHSXTAEfEAMKvoptqwHZw4ggwyVRbU9OyRYl6fh7YYCubhgk8k BcPF8l0qfolck7D5m4ewAy9VvU1PvlJc2Ytvlcye4Gt18MFzuNnwEiQ7G4KkboWBOMa2 kL6li2l8ZW+V9cz2238Vc+T3zAKCP9Ly9OO0Oxt+NN9yyB7KUHEKkKlfoR2JSpNp6CJm qH152HSLZn0Q0Ns0kVut07YrqfBvb8kfcsONsBzjomE3oTwB8frJXRTKXtkH2sDvr+dp eYAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=BNNALLtybm0oJKMVXxpLjewVCS4pX4JxD6oyP7RFsuk=; b=i/HNEWWbgYJsxnajJLpvY0djytyqvJbOFS6+Ha8EytuZXfeBk8i6K9mm7M9XwZvjsI 5/VGQdfiJeWKjsqPDjSaXOOwteHbyvE79pArhAiDnNGwOQ8/QfKpLV3qg3jEmQuXVirp sbk6eKdA+pxFSayrhhgiumEJDDLP69fQpQ6vxO6fcGqWM6JB5Tq6LWl5BE2niFlL1tyz yP9ofJ2SOidMhVCNVxoCwcLOue8x7aVs9SCD6RG16R4SaN9qOXQlvlPQF0TiXpfBL6pE eSZBq1VbP4HkS5UPyjTbtPyQh/g64b0yR9TBXaL4igMC8wiO48eAGrc9Xh7hzP0Ealgs biow== X-Gm-Message-State: ALQs6tDaCZ7BgzQDiUYPllN2FJ8ZL0eRQhAoaClhqT3lwE2Gh4ePsAdV 86xUZGa5O/HcVmikDdpzudOu0aDK X-Google-Smtp-Source: AIpwx482gmosFqUfYzNi5tm9LRqmhFC7QRMD/kTpg6uGFVMDcgy67a2qUUJ0510nrOxgHW7lzVJNcQ== X-Received: by 10.223.184.56 with SMTP id h53mr996019wrf.87.1523956155121; Tue, 17 Apr 2018 02:09:15 -0700 (PDT) Received: from [10.16.0.123] (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id v66sm8693230wmd.4.2018.04.17.02.09.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 02:09:14 -0700 (PDT) To: Yong Wang , "dev@dpdk.org" References: <20180328154349.24976-1-didier.pallard@6wind.com> <20180328154349.24976-3-didier.pallard@6wind.com> From: Didier Pallard Message-ID: Date: Tue, 17 Apr 2018 11:09:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr Subject: Re: [dpdk-dev] [PATCH 2/8] net/vmxnet3: return unknown IPv4 extension len ptype X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 09:09:15 -0000 Hi wang, Indeed, this one is not strictly needed and does not fix anything, anyway: - If application does not need the information (ethernet bridge, for example), this access is not needed and it will never be done, so application performance will be improved. - If application needs the information, you're true, the parsing will just  be shifted to the application procedure, but I think that data access locality will be increased since the application will certainly do other stuff around the same memory location. And in this case, final performance figures should be at worst the same than before the patch. Didier On 04/16/2018 09:46 PM, Yong Wang wrote: >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Didier Pallard >> Sent: Wednesday, March 28, 2018 8:44 AM >> To: dev@dpdk.org >> Subject: [dpdk-dev] [PATCH 2/8] net/vmxnet3: return unknown IPv4 >> extension len ptype >> >> Rather than parsing IP header to get proper ptype to return, just return >> RTE_PTYPE_L3_IPV4_EXT_UNKNOWN, that tells application that we have an >> IP >> packet with unknown header length. > Any specific reason of doing this? I can image there are applications that depend on this and the cost of parsing is simply shifted to the app or via rte_eth_add_rx_callback(). > >> Signed-off-by: Didier Pallard >> --- >> drivers/net/vmxnet3/vmxnet3_rxtx.c | 8 +------- >> 1 file changed, 1 insertion(+), 7 deletions(-) >> >> diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c >> b/drivers/net/vmxnet3/vmxnet3_rxtx.c >> index 3a8c62fc1..156dc8e52 100644 >> --- a/drivers/net/vmxnet3/vmxnet3_rxtx.c >> +++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c >> @@ -659,13 +659,7 @@ vmxnet3_rx_offload(const Vmxnet3_RxCompDesc >> *rcd, struct rte_mbuf *rxm) >> >> /* Check packet type, checksum errors, etc. Only support IPv4 for >> now. */ >> if (rcd->v4) { >> - struct ether_hdr *eth = rte_pktmbuf_mtod(rxm, struct >> ether_hdr *); >> - struct ipv4_hdr *ip = (struct ipv4_hdr *)(eth + 1); >> - >> - if (((ip->version_ihl & 0xf) << 2) > (int)sizeof(struct ipv4_hdr)) >> - rxm->packet_type = RTE_PTYPE_L3_IPV4_EXT; >> - else >> - rxm->packet_type = RTE_PTYPE_L3_IPV4; >> + rxm->packet_type = RTE_PTYPE_L3_IPV4_EXT_UNKNOWN; >> >> if (!rcd->cnc) { >> if (!rcd->ipc) >> -- >> 2.11.0