All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Larysa Zaremba <larysa.zaremba@intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
	intel-wired-lan@lists.osuosl.org,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Michal Swiatkowski <michal.swiatkowski@linux.intel.com>,
	Mateusz Pacuszka <mateuszx.pacuszka@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 6/6] ice: enable LLDP TX for VFs through tc
Date: Thu, 20 Feb 2025 14:59:08 +0000	[thread overview]
Message-ID: <20250220145908.GD1615191@kernel.org> (raw)
In-Reply-To: <20250214085215.2846063-7-larysa.zaremba@intel.com>

On Fri, Feb 14, 2025 at 09:50:40AM +0100, Larysa Zaremba wrote:
> Only a single VSI can be in charge of sending LLDP frames, sometimes it is
> beneficial to assign this function to a VF, that is possible to do with tc
> capabilities in the switchdev mode. It requires first blocking the PF from
> sending the LLDP frames with a following command:
> 
> tc filter add dev <ifname> egress protocol lldp flower skip_sw action drop
> 
> Then it becomes possible to configure a forward rule from a VF port
> representor to uplink instead.
> 
> tc filter add dev <vf_ifname> ingress protocol lldp flower skip_sw
> action mirred egress redirect dev <ifname>
> 
> How LLDP exclusivity was done previously is LLDP traffic was blocked for a
> whole port by a single rule and PF was bypassing that. Now at least in the
> switchdev mode, every separate VSI has to have its own drop rule. Another
> complication is the fact that tc does not respect when the driver refuses
> to delete a rule, so returning an error results in a HW rule still present
> with no way to reference it through tc. This is addressed by allowing the
> PF rule to be deleted at any time, but making the VF forward rule "dormant"
> in such case, this means it is deleted from HW but stays in tc and driver's
> bookkeeping to be restored when drop rule is added back to the PF.
> 
> Implement tc configuration handling which enables the user to transmit LLDP
> packets from VF instead of PF.
> 
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>

Reviewed-by: Simon Horman <horms@kernel.org>


WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Larysa Zaremba <larysa.zaremba@intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
	intel-wired-lan@lists.osuosl.org,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Michal Swiatkowski <michal.swiatkowski@linux.intel.com>,
	Mateusz Pacuszka <mateuszx.pacuszka@intel.com>
Subject: Re: [PATCH iwl-next v4 6/6] ice: enable LLDP TX for VFs through tc
Date: Thu, 20 Feb 2025 14:59:08 +0000	[thread overview]
Message-ID: <20250220145908.GD1615191@kernel.org> (raw)
In-Reply-To: <20250214085215.2846063-7-larysa.zaremba@intel.com>

On Fri, Feb 14, 2025 at 09:50:40AM +0100, Larysa Zaremba wrote:
> Only a single VSI can be in charge of sending LLDP frames, sometimes it is
> beneficial to assign this function to a VF, that is possible to do with tc
> capabilities in the switchdev mode. It requires first blocking the PF from
> sending the LLDP frames with a following command:
> 
> tc filter add dev <ifname> egress protocol lldp flower skip_sw action drop
> 
> Then it becomes possible to configure a forward rule from a VF port
> representor to uplink instead.
> 
> tc filter add dev <vf_ifname> ingress protocol lldp flower skip_sw
> action mirred egress redirect dev <ifname>
> 
> How LLDP exclusivity was done previously is LLDP traffic was blocked for a
> whole port by a single rule and PF was bypassing that. Now at least in the
> switchdev mode, every separate VSI has to have its own drop rule. Another
> complication is the fact that tc does not respect when the driver refuses
> to delete a rule, so returning an error results in a HW rule still present
> with no way to reference it through tc. This is addressed by allowing the
> PF rule to be deleted at any time, but making the VF forward rule "dormant"
> in such case, this means it is deleted from HW but stays in tc and driver's
> bookkeeping to be restored when drop rule is added back to the PF.
> 
> Implement tc configuration handling which enables the user to transmit LLDP
> packets from VF instead of PF.
> 
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>

Reviewed-by: Simon Horman <horms@kernel.org>


  reply	other threads:[~2025-02-20 15:04 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-14  8:50 [Intel-wired-lan] [PATCH iwl-next v4 0/6] ice: LLDP support for VFs Larysa Zaremba
2025-02-14  8:50 ` Larysa Zaremba
2025-02-14  8:50 ` [Intel-wired-lan] [PATCH iwl-next v4 1/6] ice: fix check for existing switch rule Larysa Zaremba
2025-02-14  8:50   ` Larysa Zaremba
2025-02-20 14:55   ` [Intel-wired-lan] " Simon Horman
2025-02-20 14:55     ` Simon Horman
2025-03-11 10:24     ` [Intel-wired-lan] " Romanowski, Rafal
2025-03-11 10:24       ` Romanowski, Rafal
2025-02-14  8:50 ` [Intel-wired-lan] [PATCH iwl-next v4 2/6] ice: do not add LLDP-specific filter if not necessary Larysa Zaremba
2025-02-14  8:50   ` Larysa Zaremba
2025-02-20 14:56   ` [Intel-wired-lan] " Simon Horman
2025-02-20 14:56     ` Simon Horman
2025-03-11 10:24     ` [Intel-wired-lan] " Romanowski, Rafal
2025-03-11 10:24       ` Romanowski, Rafal
2025-02-14  8:50 ` [Intel-wired-lan] [PATCH iwl-next v4 3/6] ice: receive LLDP on trusted VFs Larysa Zaremba
2025-02-14  8:50   ` Larysa Zaremba
2025-02-20 14:58   ` [Intel-wired-lan] " Simon Horman
2025-02-20 14:58     ` Simon Horman
2025-03-11 10:25     ` [Intel-wired-lan] " Romanowski, Rafal
2025-03-11 10:25       ` Romanowski, Rafal
2025-02-14  8:50 ` [Intel-wired-lan] [PATCH iwl-next v4 4/6] ice: remove headers argument from ice_tc_count_lkups Larysa Zaremba
2025-02-14  8:50   ` Larysa Zaremba
2025-02-20 14:58   ` [Intel-wired-lan] " Simon Horman
2025-02-20 14:58     ` Simon Horman
2025-03-11 10:25     ` [Intel-wired-lan] " Romanowski, Rafal
2025-03-11 10:25       ` Romanowski, Rafal
2025-02-14  8:50 ` [Intel-wired-lan] [PATCH iwl-next v4 5/6] ice: support egress drop rules on PF Larysa Zaremba
2025-02-14  8:50   ` Larysa Zaremba
2025-02-20 14:58   ` [Intel-wired-lan] " Simon Horman
2025-02-20 14:58     ` Simon Horman
2025-03-11 10:26     ` [Intel-wired-lan] " Romanowski, Rafal
2025-03-11 10:26       ` Romanowski, Rafal
2025-02-14  8:50 ` [Intel-wired-lan] [PATCH iwl-next v4 6/6] ice: enable LLDP TX for VFs through tc Larysa Zaremba
2025-02-14  8:50   ` Larysa Zaremba
2025-02-20 14:59   ` Simon Horman [this message]
2025-02-20 14:59     ` Simon Horman
2025-03-11 10:26     ` [Intel-wired-lan] " Romanowski, Rafal
2025-03-11 10:26       ` Romanowski, Rafal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250220145908.GD1615191@kernel.org \
    --to=horms@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=larysa.zaremba@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mateuszx.pacuszka@intel.com \
    --cc=michal.swiatkowski@linux.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.