| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 13 Jun 2024 00:40:04 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Siddharth Vadapalli <s-vadapalli@...com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, corbet@....net, rogerq@...nel.org,
danishanwar@...com, vladimir.oltean@....com, netdev@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, vigneshr@...com,
misael.lopez@...com, srk@...com
Subject: Re: [RFC PATCH net-next 01/28] docs: networking: ti: add driver doc
for CPSW Proxy Client
> The DMA Channels provide a path to/from CPSW's Host Port for each Host.
>
> Please refer to the following illustration corresponding to the data
> movement from each of the Hosts to the CPSW's Host Port via the ALE and
> then out of the MAC Ports:
>
> ------- --------- --------- CONTROL-PATH
> |Linux| |AUTOSAR| | EthFW | -------------
> ------- --------- --------- |
> | | | | | | |
> DATA TX RX TX RX TX RX |
> PATH => | | | | | | |
> (DMA) | | | | | | |
> | | | | | | |
> \ \ \ \ / / |
> \ \ \ \ / / |
> \ \ \ \ / / |
> \ \ \ \ / / |
> \ \ \ \ / / |
> =============================== |
> || CPSW HOST PORT || V
> =============================== -----------
> | |CPSW |
> TX + RX |CONTROL |
> | |REGISTERS|
> | -----------
> |
> ===================
> ||ALE & SWITCH CORE||
> ===================
> / | | \
> / | | \
> / | | \
> TX+RX | \ -------
> / | \ \
> / TX+RX TX+RX TX+RX
> / | \ \
> ========== ========== ========== ==========
> |MAC Port 1| |MAC Port 2| |MAC Port 3| |MAC Port 4|
> ========== ========== ========== ==========
So, in summary, you have one host port, and on top of that a number of
virtual ports. Because of limitations in the ALE, those virtual ports
don't work in the same way as real ports, replication is not possible,
nor learning for individual virtual ports. The typical 1990 solution
to that would be to flood packets to all hosts, and let them filter
out the packets they are not interested in. 1990 Ethernet was a shared
medium, you expect to see packets for other hosts. But the hardware
also cannot do that.
So you have to program the classify to augment the ALE, and the
classifier is the one that decides which virtual port a packet goes
out. But the classifier does not perform learning. You need additional
mechanisms to program that classifier.
> Host which has registered with that MAC Address "M". This is handled by
> EthFw. EthFw doesn't/cannot snoop on all traffic on the Host Port, since
> it doesn't lie in between the Host Port and the other Hosts. Rather, it
> is quite similar to a Host itself since it also has dedicated TX/RX DMA
> Channels to exchange traffic with CPSW.
I did not say snoop. I said trap. There is a difference. Snoop would
be it sees the packet, as it going by. Trap means it actually gets
passed the packet, and it needs to deal with it, decide the outgoing
port.
So i would trap all broadcast and multicast from the virtual ports to
the EthFW. Let the EthFw deal with that traffic, perform learning, and
programming the classifier, and flood it out user ports for broadcast,
or unicast out specific ports for multicast where IGMP snooping
indicates it should go.
> Since that is not supported, all
> Broadcast/Multicast traffic directed to the Host Port from the Switch Core
> is by default placed on the RX DMA Flow corresponding to EthFw. EthFw then
> creates copies of these in software and shares them with each Host via
> Shared Memory for example.
Why shared memory? EthFw needs to be able to direct packets out
specific virtual ports otherwise it cannot do {R}STP, PTP, IGMP
snooping etc. So it should just pass the packet back to the CPSW,
which will hairpin the packet, hit the classifier, and then send it
out the correct virtual port to the correct host.
> Yes, the Shared Memory path is intended for the low-bandwidth
> Broadcast/Multicast traffic from EthFw while the DMA path is dedicated
> for high-bandwidth Unicast traffic. The current series implements the
> DMA path while the other series you have referred to implements the
> Shared Memory path. Both of them together enable the desired functionality.
So i think we are agreed a new model is not needed. Linux is just a
host connected to a managed switch. Linux has no roll in managing that
switch, and has no idea about the ports of that switch. It is just an
end system, running end system software.
You need a 'MAC' driver in Linux, so Linux sees just a normal network
interface. And it must see a single MAC driver, so if you really do
need to use shared memory in parallel to DMA, you will need to combine
that into one driver.
Andrew
Powered by blists - more mailing lists