From: Vladimir Oltean <olteanv@gmail.com>
To: Ido Schimmel <idosch@idosch.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jiri Pirko <jiri@resnulli.us>, Jakub Kicinski <kuba@kernel.org>,
Ivan Vecera <ivecera@redhat.com>,
vyasevich@gmail.com, netdev <netdev@vger.kernel.org>,
UNGLinuxDriver@microchip.com,
Nikolay Aleksandrov <nikolay@cumulusnetworks.com>,
Roopa Prabhu <roopa@cumulusnetworks.com>
Subject: Re: [PATCH RFC net-next 00/13] RX filtering for DSA switches
Date: Sun, 1 Nov 2020 17:04:42 +0200 [thread overview]
Message-ID: <20201101150442.as7qfa2qh7figmsn@skbuf> (raw)
In-Reply-To: <20201101144217.GA714146@shredder>
On Sun, Nov 01, 2020 at 04:42:17PM +0200, Ido Schimmel wrote:
> If the goal of this thread is to get packet sockets to work with
> offloaded traffic, then I think you need to teach these sockets to
> instruct the bound device to trap / mirror incoming traffic to the CPU.
> Maybe via a new ndo.
A new ndo that does what? It would be exclusively called by sockets?
We have packet traps with tc, packet traps with devlink, a mechanism for
switchdev host MDBs, and from the discussion with you I also gather that
there should be an equivalent switchdev object for host FDBs, that the
bridge would use. So we would need yet another mechanism to extract
packets from the hardware data path? I am simply lacking the clarity
about what the new ndo you're talking about should do.
next prev parent reply other threads:[~2020-11-01 15:04 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-21 21:10 [PATCH RFC net-next 00/13] RX filtering for DSA switches Vladimir Oltean
2020-05-21 21:10 ` [PATCH RFC net-next 01/13] net: core: dev_addr_lists: add VID to device address Vladimir Oltean
2020-05-21 21:10 ` [PATCH RFC net-next 02/13] net: 8021q: vlan_dev: add vid tag to addresses of uc and mc lists Vladimir Oltean
2020-05-21 21:10 ` [PATCH RFC net-next 03/13] net: 8021q: vlan_dev: add vid tag for vlan device own address Vladimir Oltean
2020-05-21 21:10 ` [PATCH RFC net-next 04/13] ethernet: eth: add default vid len for all ethernet kind devices Vladimir Oltean
2020-05-21 21:10 ` [PATCH RFC net-next 05/13] net: bridge: multicast: propagate br_mc_disabled_update() return Vladimir Oltean
2020-05-21 21:10 ` [PATCH RFC net-next 06/13] net: core: dev_addr_lists: export some raw __hw_addr helpers Vladimir Oltean
2020-05-21 21:10 ` [PATCH RFC net-next 07/13] net: dsa: don't use switchdev_notifier_fdb_info in dsa_switchdev_event_work Vladimir Oltean
2020-05-21 21:10 ` [PATCH RFC net-next 08/13] net: dsa: add ability to program unicast and multicast filters for CPU port Vladimir Oltean
2020-05-21 21:10 ` [PATCH RFC net-next 09/13] net: dsa: mroute: don't panic the kernel if called without the prepare phase Vladimir Oltean
2020-05-21 21:10 ` [PATCH RFC net-next 10/13] net: bridge: add port flags for host flooding Vladimir Oltean
2020-05-22 12:38 ` Nikolay Aleksandrov
2020-05-22 13:13 ` Vladimir Oltean
2020-05-22 18:45 ` Allan W. Nielsen
2020-07-20 11:08 ` Vladimir Oltean
2020-05-24 14:26 ` Ido Schimmel
2020-05-24 16:13 ` Vladimir Oltean
2020-05-25 20:11 ` Ido Schimmel
2020-05-25 20:32 ` Vladimir Oltean
2020-07-23 22:35 ` Vladimir Oltean
2020-07-27 17:15 ` Ido Schimmel
2020-05-21 21:10 ` [PATCH RFC net-next 11/13] net: dsa: deal with new flooding port attributes from bridge Vladimir Oltean
2020-05-21 21:10 ` [PATCH RFC net-next 12/13] net: dsa: treat switchdev notifications for multicast router connected to port Vladimir Oltean
2020-05-21 21:10 ` [PATCH RFC net-next 13/13] net: dsa: wire up multicast IGMP snooping attribute notification Vladimir Oltean
2020-05-22 18:42 ` [PATCH RFC net-next 00/13] RX filtering for DSA switches Allan W. Nielsen
2020-05-24 14:06 ` Ido Schimmel
2020-05-24 16:24 ` Vladimir Oltean
2020-05-25 19:48 ` Ido Schimmel
2020-05-25 20:23 ` Vladimir Oltean
2020-05-26 14:01 ` Ido Schimmel
2020-05-27 11:36 ` Vladimir Oltean
2020-05-28 14:37 ` Ido Schimmel
2020-07-20 10:00 ` Vladimir Oltean
2020-07-27 16:56 ` Ido Schimmel
2020-10-27 11:52 ` Vladimir Oltean
2020-10-28 14:43 ` Ido Schimmel
2020-10-28 18:46 ` Vladimir Oltean
2020-11-01 11:27 ` Ido Schimmel
2020-11-01 12:06 ` Vladimir Oltean
2020-11-01 14:42 ` Ido Schimmel
2020-11-01 15:04 ` Vladimir Oltean [this message]
2020-11-01 15:39 ` Ido Schimmel
2020-11-01 16:13 ` Vladimir Oltean
2020-11-11 4:12 ` Florian Fainelli
2020-05-24 16:13 ` Florian Fainelli
2020-05-24 16:34 ` Vladimir Oltean
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=20201101150442.as7qfa2qh7figmsn@skbuf \
--to=olteanv@gmail.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=idosch@idosch.org \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=roopa@cumulusnetworks.com \
--cc=vivien.didelot@gmail.com \
--cc=vyasevich@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox