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

Ferruh Yigit ferruh.yigit at intel.com
Tue Dec 13 18:31:02 CET 2016


On 12/13/2016 5:12 PM, Ananyev, Konstantin wrote:
> 
> 
>> -----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?

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



More information about the dev mailing list