From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id F0B9B370 for ; Tue, 13 Dec 2016 18:12:16 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP; 13 Dec 2016 09:12:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,342,1477983600"; d="scan'208";a="911771380" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by orsmga003.jf.intel.com with ESMTP; 13 Dec 2016 09:12:14 -0800 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX154.ger.corp.intel.com (163.33.192.96) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 13 Dec 2016 17:12:12 +0000 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.43]) by IRSMSX156.ger.corp.intel.com ([169.254.3.74]) with mapi id 14.03.0248.002; Tue, 13 Dec 2016 17:12:11 +0000 From: "Ananyev, Konstantin" To: Michal Miroslaw CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities Thread-Index: AQHSVN2vUiCQbgUPRkeSVMP4pvrmI6EFsq3ggAA9fgCAAAI9cIAABl4AgAAAeDA= Date: Tue, 13 Dec 2016 17:12:11 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583F0E754B@irsmsx105.ger.corp.intel.com> References: <2601191342CEEE43887BDE71AB9772583F0E6E4C@irsmsx105.ger.corp.intel.com> <20161213142654.me3p5gl7muji3sei@rere.qmqm.pl> <2601191342CEEE43887BDE71AB9772583F0E70A6@irsmsx105.ger.corp.intel.com> <20161213145742.hxvtr63anhy7ai33@rere.qmqm.pl> In-Reply-To: <20161213145742.hxvtr63anhy7ai33@rere.qmqm.pl> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities 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, 13 Dec 2016 17:12:17 -0000 > -----Original Message----- > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl] > Sent: Tuesday, December 13, 2016 2:58 PM > To: Ananyev, Konstantin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities >=20 > On Tue, Dec 13, 2016 at 02:37:34PM +0000, Ananyev, Konstantin wrote: > > > > > > > -----Original Message----- > > > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl] > > > Sent: Tuesday, December 13, 2016 2:27 PM > > > To: Ananyev, Konstantin > > > Cc: dev@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities > > > > > > On Tue, Dec 13, 2016 at 10:48:32AM +0000, Ananyev, Konstantin wrote: > > > > > -----Original Message----- > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miros= law > > > > > Sent: Tuesday, December 13, 2016 1:08 AM > > > > > To: dev@dpdk.org > > > > > Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities > > > > > > > > > > From: Pawe=B3 Ma=B3achowski > > > > > > > > > > Thanks to that change we can use Null PMD for testing purposes. > > > > > > > > > > Signed-off-by: Micha=B3 Miros=B3aw > > > > > --- > > > > > drivers/net/null/rte_eth_null.c | 13 ++++++++++++- > > > > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/r= te_eth_null.c > > > > > index 836d982..f32ba2a 100644 > > > > > --- a/drivers/net/null/rte_eth_null.c > > > > > +++ b/drivers/net/null/rte_eth_null.c > > > > > @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, u= int16_t tx_queue_id, > > > > > return 0; > > > > > } > > > > > > > > > > +static void > > > > > +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; = } > > > > > + > > > > > > > > > > static void > > > > > eth_dev_info(struct rte_eth_dev *dev, > > > > > @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev, > > > > > dev_info->pci_dev =3D NULL; > > > > > dev_info->reta_size =3D internals->reta_size; > > > > > dev_info->flow_type_rss_offloads =3D internals->flow_type_rss_o= ffloads; > > > > > + /* We hereby declare we can RX-offload VLAN-s out of thin air a= nd update checksums and VLANs before sinking > packets in > > > > > /dev/null */ > > > > > + dev_info->rx_offload_capa =3D DEV_RX_OFFLOAD_VLAN_STRIP; > > > > > + dev_info->tx_offload_capa =3D DEV_TX_OFFLOAD_VLAN_INSERT | DEV_= TX_OFFLOAD_IPV4_CKSUM; > > > > > > > > Hmm, how could it be supported if all that null PMD does on TX - ju= st free the packets? > > > > Same question for RX. > > > > > > You could imagine, that before dropping the packet you insert the tag > > > and calculate the checksum. The observed effect will be the same. > > > > > > On RX this always indicates lack of VLAN tag. So whether the offload > > > is enabled or not it doesn't matter. > > > > Of course user can imagine whatever he likes, but what the point to adv= ertise these capabilities, > > when the PMD clearly doesn't have them? > > Again, why these particular ones? >=20 > Hmm. I guess we can expand the set. Those were the ones we actually use > (depend on) for testing our code. >=20 > This allows to use null PMD for testing in place of real network interfac= e > with those offloads.=20 As I can see on TX null pmd would just drop the packets, right? So the only thing you might check, as I understand, did upper layer code setup ol_flags and other mbuf fields properly depending on advertised capa= bilities (probably via sme special tx_callback installed or so). Is that correct?=20 That's ok, I suppose, but if tomorrow you (or someone else) would like to = test with different RX/TX offloads? =20 Shouldn't be advertised offload capabilities be configurable at device crea= tion/attach time somehow? Or at least just advertise all possible ones then? Konstantin >This patch is to keep users from having to place if's > around their code just to support test scenarios with null PMD. >=20 > Best Regards, > Micha=B3=A0Miros=B3aw