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

[Rahul Lakkireddy]

On Tuesday, March 03/27/18, 2018 at 22:56:44 +0530, Ferruh Yigit wrote:
> 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?
> 

Sorry for the confusion. By mistake, I replied in relation to existing
cxgbe PMD.  New device ids are already handled by Patch 1/13 for VF.
Will get the docs updated.

> > 
> >>>
> >>> 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.
> 

Replied to Shahaf in earlier mail with more details on how Chelsio HW
handles double-vlans.

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