Re: [dpdk-dev] [PATCH 00/13] cxgbe: add CXGBE VF PMD and updates

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 3/27/2018 8:01 AM, Rahul Lakkireddy wrote:
> On Tuesday, March 03/27/18, 2018 at 02:21:56 +0530, Ferruh Yigit wrote:
>> On 3/10/2018 10:48 PM, Rahul Lakkireddy wrote:
>>> Patches 1 - 9 add support for cxgbe VF driver.  Patches 10 - 12 fix
>>> bugs and convert license in cxgbe files to SPDX License Tag.  Patch
>>> 13 adds compile time option to keep outer vlan tag in Q-in-Q packet.
>>>
>>> Patch 1 adds minimal cxgbe VF driver.
>>
>> Can you please update driver documentation with new supported device?
>>
> 
> There is no addition of new devices. The existing supported devices will
> be supported for VF PMD as well.

Sorry I didn't get this part, new PMD is introduced (VF driver) but no new
device support added? If so why new driver is added?

> 
>>>
>>> Patch 2 adds firmware mailbox support for VF.
>>>
>>> Patch 3 adds base functions to enable VF ports in subsequent patches.
>>>
>>> Patch 4 adds cxgbe VF probe to initialize VF devices.
>>>
>>> Patch 5 initializes SGE and queues for VF.
>>>
>>> Patch 6 enables RSS for VF.
>>>
>>> Patch 7 updates TX and RX path for VF.
>>>
>>> Patch 8 adds support for VF port statistics.
>>>
>>> Patch 9 adds support to set mac address.
>>>
>>> Patch 10 fixes bug where the other ports under same PF are not closed
>>> properly.
>>>
>>> Patch 11 exports RSS hash functions in device info and adds check
>>> to prevent configuring unsupported hash functions.
>>>
>>> Patch 12 converts all cxgbe files to use SPDX license tag.
>>>
>>> Patch 13 adds compile time option to keep outer vlan tag in Q-in-Q
>>> packet.
>>
>> We are trying to reduce the config options, is it possible to provide this
>> functionality with a runtime option (devargs) ?
>>
> 
> Thank you for pointing to this. It seems like a good option.
> 
>> Or there is already an offload option DEV_RX_OFFLOAD_QINQ_STRIP, I guess this is
>> different (is it?), if so does it make sense to have another offload option to
>> cover your case?
>>
>>
> 
> Yes, this is different. Here, its about stripping or preserving
> Outer-VLAN tag from double-vlan in Rx. We have few customers who need
> this for their use-case. So, adding another offload option would also
> help. Let us know which is preferred - either one, devargs OR another
> offload, seems fine.

As far as I can see this is done by hw configuration, so I would think this is a
kind of offload and tend to add it as another offload flag. cc'ed Shahaf for
comment.

Out of curiosity, if it is OK, what is the use case of keeping outer-VLAN tag
but remove inner-VLAN?

> 
> Thanks,
> Rahul
>