RE: [PATCH V2 net-next 0/2] net: hns3: adds two VLAN feature
Hi Jakub/David, > From: Jakub Kicinski [mailto:k...@kernel.org] > Sent: Wednesday, May 27, 2020 8:31 PM > To: tanhuazhong > Cc: David Miller ; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; Salil Mehta ; > Zhuangyuzeng (Yisen) ; Linuxarm > Subject: Re: [PATCH V2 net-next 0/2] net: hns3: adds two VLAN feature > > On Wed, 27 May 2020 10:31:59 +0800 tanhuazhong wrote: > > Hi, Jakub & David. > > > > For patch#1, is it acceptable adding "ethtool --get-priv-flags" > > to query the VLAN. If yes, I will send a RFC for it. > > The recommended way of implementing vfs with advanced vlan > configurations is via "switchdev mode" & representors. AFAIK, switchdev ops only facilitates the standard abstract interface to any underlying standard or proprietary hardware which could be ASIC, eswitch etc. Therefore, standard tools like ip, bridge or even stacks like FRR etc. could be used while leveraging the below hardware forwarding. Not sure how will switchdev ops will be of help here? Just curious how does Mellanox supports Hybrid port mode? In general, We can have port being configured as Access/Trunk ports. Access port = Only untagged packets are sent or are expected. RX'ed Tagged packets are dropped. Trunk Port = Only Tagged packet are received or sent and any Untagged packets received are dropped. Mellanox also support Hybrid mode in Onyx platform: Hybrid - packets are sent tagged or untagged, the port expects both tagged and untagged packets. This mode is a combination of Access and Trunk modes. There is an option to configure multiple VLANs on the hybrid port. PVID is configured on the port for untagged ingress packets. First two configuration are easy to realize using the standard Linux configuration tools like ip/bridge but not sure about the hybrid? also, why do we even need to create a bridge to realize any of above port modes? Note: HNS hardware does not have eswitch support. Salil.
Re: [PATCH V2 net-next 0/2] net: hns3: adds two VLAN feature
On Wed, 27 May 2020 10:31:59 +0800 tanhuazhong wrote: > Hi, Jakub & David. > > For patch#1, is it acceptable adding "ethtool --get-priv-flags" > to query the VLAN. If yes, I will send a RFC for it. The recommended way of implementing vfs with advanced vlan configurations is via "switchdev mode" & representors.
Re: [PATCH V2 net-next 0/2] net: hns3: adds two VLAN feature
On 2020/5/22 17:35, tanhuazhong wrote: On 2020/5/22 5:37, David Miller wrote: From: Jakub Kicinski Date: Thu, 21 May 2020 12:17:07 -0700 On Thu, 21 May 2020 19:38:23 +0800 Huazhong Tan wrote: This patchset adds two new VLAN feature. [patch 1] adds a new dynamic VLAN mode. [patch 2] adds support for 'QoS' field to PVID. Change log: V1->V2: modifies [patch 1]'s commit log, suggested by Jakub Kicinski. I don't like the idea that FW is choosing the driver behavior in a way that's not observable via standard Linux APIs. This is the second time a feature like that posted for a driver this week, and we should discourage it. Agreed, this is an unacceptable approach to driver features. Hi, Jakub & David. As decribed in patch #1, there is a scenario which needs the dynamic mode(port VLAN filter is always disabled, andVF VLAN filter is keep disable until a non-zero VLAN ID being used for the function). Is this mode selection provided through "ethtool --set-priv-flags" more acceptable? Or is there any other better suggestion for this? Thanks. Hi, Jakub & David. For patch#1, is it acceptable adding "ethtool --get-priv-flags" to query the VLAN. If yes, I will send a RFC for it. Best Regards. Thanks. .
Re: [PATCH V2 net-next 0/2] net: hns3: adds two VLAN feature
On 2020/5/22 5:37, David Miller wrote: From: Jakub Kicinski Date: Thu, 21 May 2020 12:17:07 -0700 On Thu, 21 May 2020 19:38:23 +0800 Huazhong Tan wrote: This patchset adds two new VLAN feature. [patch 1] adds a new dynamic VLAN mode. [patch 2] adds support for 'QoS' field to PVID. Change log: V1->V2: modifies [patch 1]'s commit log, suggested by Jakub Kicinski. I don't like the idea that FW is choosing the driver behavior in a way that's not observable via standard Linux APIs. This is the second time a feature like that posted for a driver this week, and we should discourage it. Agreed, this is an unacceptable approach to driver features. Hi, Jakub & David. As decribed in patch #1, there is a scenario which needs the dynamic mode(port VLAN filter is always disabled, andVF VLAN filter is keep disable until a non-zero VLAN ID being used for the function). Is this mode selection provided through "ethtool --set-priv-flags" more acceptable? Or is there any other better suggestion for this? Thanks. .
Re: [PATCH V2 net-next 0/2] net: hns3: adds two VLAN feature
From: Jakub Kicinski Date: Thu, 21 May 2020 12:17:07 -0700 > On Thu, 21 May 2020 19:38:23 +0800 Huazhong Tan wrote: >> This patchset adds two new VLAN feature. >> >> [patch 1] adds a new dynamic VLAN mode. >> [patch 2] adds support for 'QoS' field to PVID. >> >> Change log: >> V1->V2: modifies [patch 1]'s commit log, suggested by Jakub Kicinski. > > I don't like the idea that FW is choosing the driver behavior in a way > that's not observable via standard Linux APIs. This is the second time > a feature like that posted for a driver this week, and we should > discourage it. Agreed, this is an unacceptable approach to driver features.
Re: [PATCH V2 net-next 0/2] net: hns3: adds two VLAN feature
On Thu, 21 May 2020 19:38:23 +0800 Huazhong Tan wrote: > This patchset adds two new VLAN feature. > > [patch 1] adds a new dynamic VLAN mode. > [patch 2] adds support for 'QoS' field to PVID. > > Change log: > V1->V2: modifies [patch 1]'s commit log, suggested by Jakub Kicinski. I don't like the idea that FW is choosing the driver behavior in a way that's not observable via standard Linux APIs. This is the second time a feature like that posted for a driver this week, and we should discourage it.