From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 82DA11B8C9 for ; Fri, 11 Jan 2019 09:28:57 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 0BDBF9C0059; Fri, 11 Jan 2019 08:28:56 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 11 Jan 2019 08:28:49 +0000 To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , "Stephen Hemminger" , Rami Rosen CC: Thomas Monjalon , , , References: <98CBD80474FA8B44BF855DF32C47DC35B425B1@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35B425B8@smartserver.smartshare.dk> <3446539.r5cUhzCBca@xps> <20190110161158.0177a203@hermes.lan> <73285400-c67b-48cf-88be-b20bb05b5484@solarflare.com> <98CBD80474FA8B44BF855DF32C47DC35B425C9@smartserver.smartshare.dk> From: Andrew Rybchenko Message-ID: Date: Fri, 11 Jan 2019 11:28:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35B425C9@smartserver.smartshare.dk> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24352.003 X-TM-AS-Result: No-4.307000-8.000000-10 X-TMASE-MatchedRID: HXSqh3WYKfsOwH4pD14DsPHkpkyUphL9X5TqQagR07dyy4XsdBRYmzCH Bv5Fitn/7OAfFqssBOy8N9yPVs68B8y+OuBPEc+kWwEoK+YJxNtimi8LvNfmr8UmcSma304Tgr9 tREWYnfW94aIPzSL5XtDPd8aidMTvDRAXHVIwGYPBtFDYGmaWKpkShYcLpGH9H06W6rwtvNXN2W jbpqXgofa8+G6VxpdYgWg8WzvAdS0FrDF4OCzISWY0Io4Kxb86x22bBvE+WY47LF3pX3rdVLjxa 5EVBV1q585VzGMOFzBrAahQGwQmt7ufye8u2IC03bziTfEaC6rFgG7tYOzYsMjJz5yFtZ60KISU poTJBMZ8jgEYETf+1oEgn1YzuD0apcFSuMI8AbFbBer8KAe+u9EUlkGhCrdF1LrL2+fXuOvjSeK +NfV+VKDcIBuWXYM8qE0Kl6ggPAOI5zE67yZyQ5n3dB1BpxUEm3pIQOIJ7GinNpUKLkqur77rwe oAIK8o X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--4.307000-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24352.003 X-MDID: 1547195336-WOkavVSQafRx Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC] function to parse packet headers 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: Fri, 11 Jan 2019 08:28:57 -0000 On 1/11/19 11:16 AM, Morten Brørup wrote: >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Andrew Rybchenko >> On 1/11/19 3:11 AM, Stephen Hemminger wrote: >>> All drivers that don't have hardware support for getting l2/l3 and >>> ptype information should be calling rte_net_get_ptype() already. >> Is it documented somewhere? >> > The drivers need to parse the packet headers to set MBUF->packet_type, and without hardware support for it, the alternative to calling rte_net_get_ptype() is implementing duplicate code in the driver. I'm sorry, but I see it a bit different. The driver provides rte_eth_dev_get_supported_ptypes(). If nothing is promised, nothing may be provided. If application needs more ptypes, it can call the library function and obtain required information. If application does not need ptypes, what the point to do ptype discovery in SW and through it away? > In other words, you can interpret Stephen's "should be" as "would be silly if not". :-) > > > Med venlig hilsen / kind regards > - Morten Brørup > > >