[dpdk-dev] [PATCH 06/13] null: fake PMD capabilities

Ananyev, Konstantin konstantin.ananyev at intel.com
Tue Dec 13 18:12:11 CET 2016



> -----Original Message-----
> From: Michal Miroslaw [mailto:mirq-linux at rere.qmqm.pl]
> Sent: Tuesday, December 13, 2016 2:58 PM
> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> 
> On Tue, Dec 13, 2016 at 02:37:34PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michal Miroslaw [mailto:mirq-linux at rere.qmqm.pl]
> > > Sent: Tuesday, December 13, 2016 2:27 PM
> > > To: Ananyev, Konstantin <konstantin.ananyev at intel.com>
> > > Cc: dev at 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 at dpdk.org] On Behalf Of Michal Miroslaw
> > > > > Sent: Tuesday, December 13, 2016 1:08 AM
> > > > > To: dev at dpdk.org
> > > > > Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > > > >
> > > > > From: Paweł Małachowski <pawel.malachowski at atendesoftware.pl>
> > > > >
> > > > > Thanks to that change we can use Null PMD for testing purposes.
> > > > >
> > > > > Signed-off-by: Michał Mirosław <michal.miroslaw at atendesoftware.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/rte_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, uint16_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 = NULL;
> > > > >  	dev_info->reta_size = internals->reta_size;
> > > > >  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
> > > > > +	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking
> packets in
> > > > > /dev/null */
> > > > > +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
> > > > > +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
> > > >
> > > > Hmm, how could it be supported if all that null PMD does on TX - just 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 advertise these capabilities,
> > when the PMD clearly doesn't have them?
> > Again, why these particular ones?
> 
> Hmm. I guess we can expand the set. Those were the ones we actually use
> (depend on) for testing our code.
> 
> This allows to use null PMD for testing in place of real network interface
> with those offloads. 

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 capabilities
(probably via sme special tx_callback installed  or so).
Is that correct? 
That's ok, I  suppose, but if tomorrow you (or someone else) would like to test
with different RX/TX offloads?   
Shouldn't be advertised offload capabilities be configurable at device creation/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.
> 
> Best Regards,
> Michał Mirosław


More information about the dev mailing list