Re: [PATCH net-next v2 0/8] Add Xilinx TSN Endpoint Ethernet MAC driver
From: Neeli, Srinivas
Date: Wed Sep 16 2026 - 04:24:31 EST
Hi Jakub,
On 9/16/2026 5:52 AM, Jakub Kicinski wrote:
On Wed, 9 Sep 2026 00:49:48 +0530 Srinivas Neeli wrote:When we sent the RFC(https://lore.kernel.org/lkml/5f884e29-151a-4ee7-9e1a-d7e1f84d9f6c@xxxxxxx/), Andrew framed the choice as: if the host sees a netdev connected to a port of the switch, it is most likely a DSA switch. That matches our hardware,
This series adds the wrapper and endpoint side of the IP. The switch-facingI'm not sure why you're implementing this as DSA.
part is exposed through the Distributed Switch Architecture (DSA) framework
in a follow-up series, so that MAC1 and MAC2 show up to Linux as switch
ports with the endpoint acting as the CPU/conduit port. The endpoint frames
are already classified by source-port id and tagged with DSA port metadata
here, so the switch series can consume them without further endpoint
change.
This needs to be explained, if a single driver can bind and control
the whole thing, that's AFAIU preferable. You can keep the
implementation details in the driver without exposing the conduit
to user space
the host sees the Endpoint as a netdev on a switch port, with the two external MACs as user ports, so we implemented it as DSA.
The Endpoint is not only the switch conduit. It is also a scheduling endpoint in its own. It drives a dedicated hardware block for time-triggered per-stream
scheduling (IEEE 802.1Qcc-2018, Annex U.1.3, "Using per-stream scheduling"). That block is armed by a schedule programmed on the Endpoint's own Qbv scheduler, which acts
as its time trigger. Configuring that schedule and the per-stream trigger requires an Endpoint netdev, so we keep it to expose the Endpoint's Qbv/taprio configuration,
distinct from the wire-port schedules on the user netdevs.
On the data path, DSA maps onto the hardware cleanly. On RX, the EP DMA path delivers the source port in sideband metadata, which feeds DSA's existing metadata-based
demultiplexing to the per-port netdevs. On TX, the normal data path has no destination-port selector and the switch has no independent per-port forwarding mask, so
standalone isolation is done with a private VLAN containing only the selected port and the EP. The next version uses DSA's tag_8021q helpers to manage those VLANs, insert
the destination port's VLAN tag (which the hardware strips before wire egress), and handle the transitions between standalone and bridged operation.
A single driver could control the whole block, but it would still have to reimplement the same pieces, RX demultiplexing, TX tagging, the VLAN lifecycle, and the per-port
netdevs. We chose DSA to reuse that existing infrastructure while keeping the Endpoint and wire-port scheduling controls separate.
Thanks,
Srinivas Neeli