From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B1F9DA00E6 for ; Wed, 7 Aug 2019 01:15:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C42DA1B942; Wed, 7 Aug 2019 01:15:15 +0200 (CEST) Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) by dpdk.org (Postfix) with ESMTP id 064731B93E for ; Wed, 7 Aug 2019 01:15:13 +0200 (CEST) Received: by mail-pf1-f194.google.com with SMTP id p184so42325993pfp.7 for ; Tue, 06 Aug 2019 16:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=xjMoYU2JkS+5fZ+sw/oSeuVXW9+dQye4v+Hli03yNXw=; b=yNSNCevZz85I2rC4q/H5jkTABNkfKAEfN4T0ZfOfZA+frI4y1cm0wwMMt06cRPNo3X CeU/Gj3qLY6j853xQE8cYG2x6yJMtamoakfaOv1Q5G0bVFtZGTlzvBp38RkvFAg6684c 9F8s9cnE0Xmr+WVgbfj9BKN2sFRndM1pX5svwz4WJXx7zIMkpIEINm5GR6WQJuKhDvQC gB4tr5Cfxb0o9aaL0N9JE26SncvwMyQ4Up7BAfgIi5VWnThVtJecFPpENcJY3YKV2kuK QpVNr+LRAByGd98edVRN7zFlKqJ144FsfRiOWsVUx5PSasnA7zDI7CEVrWCJn+KnLgRb 40pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=xjMoYU2JkS+5fZ+sw/oSeuVXW9+dQye4v+Hli03yNXw=; b=cUSi9uVDyhZkhu39d6D8/AmzRloALa3G4Zc7o05S/hd3jIZAunT57Fy5YkzuDAVdYi UqwmIMybkrME9zxBREpxgzQBwr3bJfYaRH3cS2tk+oQYWUHiuTAN0x1r/JffPA2ir43L cIok7JopyPqFbsg90IDWwGzxJ5vgr6ef7/sC6J/WeFBqp0XIyBiWo+a3KGpDSJWEK8Vg i2OPgzBQdSc+JNiThCyTRw8C/eImWAcSWJ4muPxzHA7oSTTeYgeMLRIfohIeN4rQzryn TO9RnJqp6LSeuMtC/mVYEZFx1SkM/fe7jIfz3VNEcHuGw6VABIy07jiBdd+zaEvPufg9 QLXw== X-Gm-Message-State: APjAAAWpMqhYwHYLByjWfuMoN7ZpC80KYJNiQLgKx2tGf/9yrBi0E7sR XMJj5Hp1o5XGg1oX68QX+1vqlQ== X-Google-Smtp-Source: APXvYqyCv/Jc4bBGfCEn4Fsp4S94wcND5vsK4LfdOLJPcDpcPv6y8SV6FyhZOXRDZNqU4LyhjgqZeQ== X-Received: by 2002:a17:90a:c68c:: with SMTP id n12mr5608776pjt.29.1565133313021; Tue, 06 Aug 2019 16:15:13 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id d8sm81896457pgh.45.2019.08.06.16.15.12 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 06 Aug 2019 16:15:12 -0700 (PDT) Date: Tue, 6 Aug 2019 16:15:05 -0700 From: Stephen Hemminger To: Andrew Rybchenko Cc: Pavan Nikhilesh Bhagavatula , Hemant Agrawal , Jerin Jacob Kollanukkaran , "dev@dpdk.org" Message-ID: <20190806161505.36a4eed8@hermes.lan> In-Reply-To: <93b4326d-6eb2-4f31-44bf-b9dd7e91aac4@solarflare.com> References: <20190806080206.1572-1-pbhagavatula@marvell.com> <93b4326d-6eb2-4f31-44bf-b9dd7e91aac4@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 6 Aug 2019 12:06:35 +0300 Andrew Rybchenko wrote: > On 8/6/19 11:47 AM, Pavan Nikhilesh Bhagavatula wrote: > > > >> -----Original Message----- > >> From: Hemant Agrawal > >> Sent: Tuesday, August 6, 2019 1:49 PM > >> To: Pavan Nikhilesh Bhagavatula ; Jerin > >> Jacob Kollanukkaran > >> Cc: dev@dpdk.org > >> Subject: RE: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload > >>> Add PTYPE to DEV_RX_OFFLOAD_* flags. > >>> > >>> Currently, most of the NICs already support PTYPE parsing and update > >> the > >>> mbuf->packet_type through an internal lookup table, but there is no > >> way to > >>> disable the lookup if the application is not intrested in ptypes > >> returned by > >>> `rte_eth_dev_get_supported_ptypes`. > >>> > >> [Hemant] it will also mean introducing another check in datapath, if the > >> application has asked for PTYPE offload - copy the results to mbuf- > >>> packet_type otherwise don't do it. > > I think that having the check would give better performance than loading ptype table to L1 > > doing a lookup and copying it to mbuf when the application doesn't need it. > > Anyway, if PMD decides that it is better to always provide packet type > information - there is no harm. Basically if the offload is not requested > it makes packet_type undefined in mbuf. > > >> Your second patch is incomplete in the sense that it only adds the > >> capability. But it does not disable the lookups? > > It is upto the maintainer of the PMD to disable the lookup in data path. If there is a scope of optimization > > then they could do it. There is no harm in exposing PTYPE even RX_OFFLOAD_PTYPE is not enabled. > > I was hesitant to touch data path as it would be impossible to verify performance effect on all NICs. > > I think it is the right way to approach it especially taking transition > into account. > With hardline API policy, this has to fail on compile for old applications. You can't magically assume that applications using ptype will set new feature.