[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