On 12/13/2016 5:12 PM, Ananyev, Konstantin wrote: > > >> -----Original Message----- >> From: Michal Miroslaw [mailto:mirq-li...@rere.qmqm.pl] >> Sent: Tuesday, December 13, 2016 2:58 PM >> To: Ananyev, Konstantin <konstantin.anan...@intel.com> >> Cc: dev@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-li...@rere.qmqm.pl] >>>> Sent: Tuesday, December 13, 2016 2:27 PM >>>> To: Ananyev, Konstantin <konstantin.anan...@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-boun...@dpdk.org] On Behalf Of Michal Miroslaw >>>>>> Sent: Tuesday, December 13, 2016 1:08 AM >>>>>> To: dev@dpdk.org >>>>>> Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities >>>>>> >>>>>> From: Paweł Małachowski <pawel.malachow...@atendesoftware.pl> >>>>>> >>>>>> Thanks to that change we can use Null PMD for testing purposes. >>>>>> >>>>>> Signed-off-by: Michał Mirosław <michal.miros...@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?
This sounds good. Getting offload capabilities on runtime as devargs. > 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
