Re: [PATCH net-next v2 0/8] Add Xilinx TSN Endpoint Ethernet MAC driver

["Neeli, Srinivas" <srneeli@amd.com>]

Hi Jakub,

On 9/16/2026 5:52 AM, Jakub Kicinski wrote:
> On Wed, 9 Sep 2026 00:49:48 +0530 Srinivas Neeli wrote:
>> This series adds the wrapper and endpoint side of the IP. The switch-facing
>> 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.
> I'm not sure why you're implementing this as DSA.
> 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
When we sent the 
RFC(https://lore.kernel.org/lkml/5f884e29-151a-4ee7-9e1a-d7e1f84d9f6c@lunn.ch/), 
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,
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