From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <konstantin.ananyev@intel.com>
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
by dpdk.org (Postfix) with ESMTP id F0B9B370
for <dev@dpdk.org>; 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" <konstantin.ananyev@intel.com>
To: Michal Miroslaw <mirq-linux@rere.qmqm.pl>
CC: "dev@dpdk.org" <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: <cover.1481590851.git.mirq-linux@rere.qmqm.pl>
<d393aff59d03e46fc878f874e30ba53216efb396.1481590851.git.mirq-linux@rere.qmqm.pl>
<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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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 <konstantin.ananyev@intel.com>
> 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 <konstantin.ananyev@intel.com>
> > > 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 <pawel.malachowski@atendesoftware.pl>
> > > > >
> > > > > Thanks to that change we can use Null PMD for testing purposes.
> > > > >
> > > > > Signed-off-by: Micha=B3 Miros=B3aw <michal.miroslaw@atendesoftwar=
e.pl>
> > > > > ---
> > > > > 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