From: Jakub Kicinski <kuba@kernel.org>
To: Larysa Zaremba <larysa.zaremba@intel.com>
Cc: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>,
Jiri Pirko <jiri@resnulli.us>, Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
Mateusz Pacuszka <mateuszx.pacuszka@intel.com>,
Mateusz Polchlopek <mateusz.polchlopek@intel.com>,
linux-kernel@vger.kernel.org,
Jakub Buchocki <jakubx.buchocki@intel.com>,
Pawel Chmielewski <pawel.chmielewski@intel.com>,
Lukasz Plachno <lukasz.plachno@intel.com>,
intel-wired-lan@lists.osuosl.org,
Pawel Kaminski <pawel.kaminski@intel.com>,
netdev@vger.kernel.org, Tony Nguyen <anthony.l.nguyen@intel.com>,
Paolo Abeni <pabeni@redhat.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net 0/5] ice: LLDP support for VFs
Date: Tue, 5 Mar 2024 11:54:50 -0800 [thread overview]
Message-ID: <20240305115450.577c161e@kernel.org> (raw)
In-Reply-To: <ZeJ3u2x3Ihs8WQJn@lzaremba-mobl.ger.corp.intel.com>
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?
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Larysa Zaremba <larysa.zaremba@intel.com>
Cc: Jiri Pirko <jiri@resnulli.us>, <intel-wired-lan@lists.osuosl.org>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Mateusz Pacuszka <mateuszx.pacuszka@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Lukasz Plachno <lukasz.plachno@intel.com>,
Jakub Buchocki <jakubx.buchocki@intel.com>,
Pawel Kaminski <pawel.kaminski@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Michal Swiatkowski <michal.swiatkowski@linux.intel.com>,
Mateusz Polchlopek <mateusz.polchlopek@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
"Pawel Chmielewski" <pawel.chmielewski@intel.com>,
Jesse Brandeburg <jesse.brandeburg@intel.com>
Subject: Re: [PATCH iwl-net 0/5] ice: LLDP support for VFs
Date: Tue, 5 Mar 2024 11:54:50 -0800 [thread overview]
Message-ID: <20240305115450.577c161e@kernel.org> (raw)
In-Reply-To: <ZeJ3u2x3Ihs8WQJn@lzaremba-mobl.ger.corp.intel.com>
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?
next prev parent reply other threads:[~2024-03-05 19:54 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-28 15:59 [Intel-wired-lan] [PATCH iwl-net 0/5] ice: LLDP support for VFs Larysa Zaremba
2024-02-28 15:59 ` Larysa Zaremba
2024-02-28 15:59 ` [Intel-wired-lan] [PATCH iwl-net 1/5] ice: Add function to get VF from device struct Larysa Zaremba
2024-02-28 15:59 ` Larysa Zaremba
2024-02-28 15:59 ` [Intel-wired-lan] [PATCH iwl-net 2/5] ice: Fix check for existing switch rule Larysa Zaremba
2024-02-28 15:59 ` Larysa Zaremba
2024-02-28 15:59 ` [Intel-wired-lan] [PATCH iwl-net 3/5] ice: Do not add LLDP-specific filter Larysa Zaremba
2024-02-28 15:59 ` Larysa Zaremba
2024-02-28 15:59 ` [Intel-wired-lan] [PATCH iwl-net 4/5] ice: Implement VF LLDP RX support on VF Larysa Zaremba
2024-02-28 15:59 ` Larysa Zaremba
2024-02-29 9:12 ` [Intel-wired-lan] " Jiri Pirko
2024-02-29 9:12 ` Jiri Pirko
2024-02-28 15:59 ` [Intel-wired-lan] [PATCH iwl-net 5/5] ice: Implement VF LLDP TX support for VF Larysa Zaremba
2024-02-28 15:59 ` Larysa Zaremba
2024-02-28 16:47 ` [Intel-wired-lan] [PATCH iwl-net 0/5] ice: LLDP support for VFs Jakub Kicinski
2024-02-28 16:47 ` Jakub Kicinski
2024-02-29 9:20 ` [Intel-wired-lan] " Jiri Pirko
2024-02-29 9:20 ` Jiri Pirko
2024-02-29 15:28 ` [Intel-wired-lan] " Jakub Kicinski
2024-02-29 15:28 ` Jakub Kicinski
2024-02-29 19:33 ` [Intel-wired-lan] " Larysa Zaremba
2024-02-29 19:33 ` Larysa Zaremba
2024-03-01 17:08 ` [Intel-wired-lan] " Jakub Kicinski
2024-03-01 17:08 ` Jakub Kicinski
2024-03-02 0:50 ` [Intel-wired-lan] " Larysa Zaremba
2024-03-02 0:50 ` Larysa Zaremba
2024-03-05 19:54 ` Jakub Kicinski [this message]
2024-03-05 19:54 ` Jakub Kicinski
2024-03-02 6:47 ` [Intel-wired-lan] " Larysa Zaremba
2024-03-02 6:47 ` Larysa Zaremba
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=20240305115450.577c161e@kernel.org \
--to=kuba@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jakubx.buchocki@intel.com \
--cc=jiri@resnulli.us \
--cc=larysa.zaremba@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.plachno@intel.com \
--cc=mateusz.polchlopek@intel.com \
--cc=mateuszx.pacuszka@intel.com \
--cc=michal.swiatkowski@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pawel.chmielewski@intel.com \
--cc=pawel.kaminski@intel.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.