drivers/net/ethernet/intel/ice/ice.h | 2 + .../net/ethernet/intel/ice/ice_adminq_cmd.h | 1 - drivers/net/ethernet/intel/ice/ice_common.c | 26 -- drivers/net/ethernet/intel/ice/ice_common.h | 2 - drivers/net/ethernet/intel/ice/ice_ethtool.c | 6 +- drivers/net/ethernet/intel/ice/ice_lib.c | 83 +++++- drivers/net/ethernet/intel/ice/ice_lib.h | 4 + drivers/net/ethernet/intel/ice/ice_main.c | 58 ++++ drivers/net/ethernet/intel/ice/ice_sriov.c | 4 + drivers/net/ethernet/intel/ice/ice_switch.c | 4 +- drivers/net/ethernet/intel/ice/ice_vf_lib.c | 252 ++++++++++++++++++ drivers/net/ethernet/intel/ice/ice_vf_lib.h | 26 ++ drivers/net/ethernet/intel/ice/ice_virtchnl.c | 11 + 13 files changed, 439 insertions(+), 40 deletions(-)
Allow to: * receive LLDP packets on a VF * transmit LLDP from a VF Only a single VF per port can transmit LLDP packets, all trusted VFs can transmit LLDP packets. For both functionalities to work, private flag fw-lldp-agent must be off. I am aware that implemented way of configuration (through sysfs) can be potentially controversial and would like some feedback from outside. Larysa Zaremba (1): ice: Do not add LLDP-specific filter Mateusz Pacuszka (3): ice: Fix check for existing switch rule ice: Implement VF LLDP RX support on VF ice: Implement VF LLDP TX support for VF Mateusz Polchlopek (1): ice: Add function to get VF from device struct drivers/net/ethernet/intel/ice/ice.h | 2 + .../net/ethernet/intel/ice/ice_adminq_cmd.h | 1 - drivers/net/ethernet/intel/ice/ice_common.c | 26 -- drivers/net/ethernet/intel/ice/ice_common.h | 2 - drivers/net/ethernet/intel/ice/ice_ethtool.c | 6 +- drivers/net/ethernet/intel/ice/ice_lib.c | 83 +++++- drivers/net/ethernet/intel/ice/ice_lib.h | 4 + drivers/net/ethernet/intel/ice/ice_main.c | 58 ++++ drivers/net/ethernet/intel/ice/ice_sriov.c | 4 + drivers/net/ethernet/intel/ice/ice_switch.c | 4 +- drivers/net/ethernet/intel/ice/ice_vf_lib.c | 252 ++++++++++++++++++ drivers/net/ethernet/intel/ice/ice_vf_lib.h | 26 ++ drivers/net/ethernet/intel/ice/ice_virtchnl.c | 11 + 13 files changed, 439 insertions(+), 40 deletions(-) -- 2.43.0
On Wed, 28 Feb 2024 16:59:44 +0100 Larysa Zaremba wrote: > Allow to: > * receive LLDP packets on a VF > * transmit LLDP from a VF > > Only a single VF per port can transmit LLDP packets, > all trusted VFs can transmit LLDP packets. > > For both functionalities to work, private flag > fw-lldp-agent must be off. > > I am aware that implemented way of configuration (through sysfs) can be > potentially controversial and would like some feedback from outside. Why is the device not in switchdev mode? You can put your lldp-agent priv flag on repr netdevs.
Wed, Feb 28, 2024 at 05:47:45PM CET, kuba@kernel.org wrote: >On Wed, 28 Feb 2024 16:59:44 +0100 Larysa Zaremba wrote: >> Allow to: >> * receive LLDP packets on a VF >> * transmit LLDP from a VF >> >> Only a single VF per port can transmit LLDP packets, >> all trusted VFs can transmit LLDP packets. >> >> For both functionalities to work, private flag >> fw-lldp-agent must be off. >> >> I am aware that implemented way of configuration (through sysfs) can be >> potentially controversial and would like some feedback from outside. > >Why is the device not in switchdev mode? You can put your lldp-agent >priv flag on repr netdevs. > But isn't it a matter of eswitch configuration? I mean, the user should be free to configure filtering/forwarding of any packet, including LLDP ones.
On Thu, 29 Feb 2024 10:20:05 +0100 Jiri Pirko wrote: > But isn't it a matter of eswitch configuration? I mean, the user should > be free to configure filtering/forwarding of any packet, including LLDP > ones. This is an LLDP agent which runs as part of the NIC FW, AFAIU, not about forwarding or filtering. They already have the priv flag, so best to reuse that. If not possible we can explore options, but as Larysa mentioned herself in the cover letter sysfs is probably low on the preference list :(
On Thu, Feb 29, 2024 at 07:28:13AM -0800, Jakub Kicinski wrote: > On Thu, 29 Feb 2024 10:20:05 +0100 Jiri Pirko wrote: > > But isn't it a matter of eswitch configuration? I mean, the user should > > be free to configure filtering/forwarding of any packet, including LLDP > > ones. > > This is an LLDP agent which runs as part of the NIC FW, AFAIU, not about > forwarding or filtering. > > They already have the priv flag, so best to reuse that. If not possible > we can explore options, but as Larysa mentioned herself in the cover > letter sysfs is probably low on the preference list :( > FW agent is disabled NIC-wide, so only PF should be able to set such flag. The lazy part of me likes the private flag direction, because just replacing sysfs entries with corresponding private flags would make patch look better while not changing the implementation much. I guess, treating it like a normal eswitch configuration would be ideal, but it would not be purely generic, as there is an added level of complexity because of FW Agent interactions.
On Thu, 29 Feb 2024 20:33:04 +0100 Larysa Zaremba wrote: > > This is an LLDP agent which runs as part of the NIC FW, AFAIU, not about > > forwarding or filtering. > > > > They already have the priv flag, so best to reuse that. If not possible > > we can explore options, but as Larysa mentioned herself in the cover > > letter sysfs is probably low on the preference list :( > > FW agent is disabled NIC-wide, so only PF should be able to set such flag. Sorry, then I misread. If it's about which VF gets the LLDP traffic from the _wire_, then I'm with Jiri. It's a basic forwarding problem, isn't it? Match on EtherType and forward? > The lazy part of me likes the private flag direction, because just > replacing sysfs entries with corresponding private flags would make > patch look better while not changing the implementation much. > > I guess, treating it like a normal eswitch configuration would be > ideal, but it would not be purely generic, as there is an added level > of complexity because of FW Agent interactions.
On Fri, Mar 01, 2024 at 09:08:36AM -0800, Jakub Kicinski wrote: > On Thu, 29 Feb 2024 20:33:04 +0100 Larysa Zaremba wrote: > > > This is an LLDP agent which runs as part of the NIC FW, AFAIU, not about > > > forwarding or filtering. > > > > > > They already have the priv flag, so best to reuse that. If not possible > > > we can explore options, but as Larysa mentioned herself in the cover > > > letter sysfs is probably low on the preference list :( > > > > FW agent is disabled NIC-wide, so only PF should be able to set such flag. > > Sorry, then I misread. If it's about which VF gets the LLDP traffic > from the _wire_, then I'm with Jiri. It's a basic forwarding problem, > isn't it? Match on EtherType and forward? > For RX: match on Ethertype and mirror, every trusted VF should be able to scan neighbors. For TX this is more complicated and is done not through eswitch, but through modifying security options, so do not think this would work with tc. So private flags are the best option? Our requirements say only a single VSI can transmit LLDP. > > The lazy part of me likes the private flag direction, because just > > replacing sysfs entries with corresponding private flags would make > > patch look better while not changing the implementation much. > > > > I guess, treating it like a normal eswitch configuration would be > > ideal, but it would not be purely generic, as there is an added level > > of complexity because of FW Agent interactions. >
On Sat, 2 Mar 2024 01:50:03 +0100 Larysa Zaremba wrote: > For RX: match on Ethertype and mirror, every trusted VF should be able to scan > neighbors. > > For TX this is more complicated and is done not through eswitch, but through > modifying security options, so do not think this would work with tc. So private > flags are the best option? Our requirements say only a single VSI can transmit > LLDP. It is doable theoretically, tho, right? Driver can detect that all eswitch VF/PF ports but one have a "drop LLDP" rule and update the security option correctly?
On Tue, Mar 05, 2024 at 11:54:50AM -0800, Jakub Kicinski wrote: > On Sat, 2 Mar 2024 01:50:03 +0100 Larysa Zaremba wrote: > > For RX: match on Ethertype and mirror, every trusted VF should be able to scan > > neighbors. > > > > For TX this is more complicated and is done not through eswitch, but through > > modifying security options, so do not think this would work with tc. So private > > flags are the best option? Our requirements say only a single VSI can transmit > > LLDP. > > It is doable theoretically, tho, right? Driver can detect that all > eswitch VF/PF ports but one have a "drop LLDP" rule and update the > security option correctly? I can envision that. I'll report in this thread, if I encounter roadblocks, when doing v2. Thanks!
© 2016 - 2026 Red Hat, Inc.