On 3/26/19 3:38 PM, Vladimir Oltean wrote:

On 3/27/19 12:13 AM, Florian Fainelli wrote:

quoted

On 3/26/19 3:03 PM, Vladimir Oltean wrote:

quoted

On 3/26/19 4:31 AM, Florian Fainelli wrote:

quoted

On 3/23/2019 8:23 PM, Vladimir Oltean wrote:

quoted

In order to support this, we are creating a make-shift switch tag
out of
a VLAN trunk configured on the CPU port. Termination on switch ports
only works when not under a vlan_filtering bridge. We are making
use of
the generic CONFIG_NET_DSA_TAG_8021Q code and leveraging it from
our own
CONFIG_NET_DSA_TAG_SJA1105.

There are two types of traffic: regular and link-local.
The link-local traffic received on the CPU port is trapped from the
switch's regular forwarding decisions because it matched one of the
two
DMAC filters for management traffic.
On transmission, the switch requires special massaging for these
link-local frames. Due to a weird implementation of the switching
IP, by
default it drops link-local frames that originate on the CPU port. It
needs to be told where to forward them to, through an SPI command
("management route") that is valid for only a single frame.
So when we're sending link-local traffic, we need to clone skb's from
DSA and send them in our custom xmit worker that also performs SPI
access.

For that purpose, the DSA xmit handler and the xmit worker communicate
through a per-port "skb ring" software structure, with a producer
and a
consumer index. At the moment this structure is rather fragile
(ping-flooding to a link-local DMAC would cause most of the frames to
get dropped). I would like to move the management traffic on a
separate
netdev queue that I can stop when the skb ring got full and
hardware is
busy processing, so that we are not forced to drop traffic.

Signed-off-by: Vladimir Oltean <olteanv@gmail.com>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

I do like the idea of setting up specific management queue later on,
although it is not clear to me how you would go about integrating it as
a network device, given the DSA slave and master devices, do you know
roughly how you would proceed?

Actually I was thinking about leveraging the multiqueue support that you
added in 55199df6d2af ("net: dsa: Allow switch drivers to indicate
number of TX queues") and expose the slave netdev .ndo_select_queue
callback towards DSA ports. There I would return queue #0 if
sja1105_is_link_local(skb), and queue #1 otherwise.
Are there any complications that I'm missing?

So that queue could be used to steer management traffic, but it would
still attempt to perform a dev_queue_xmit() using the master DSA network
device unless you somehow change that and/or parent that queue to a
different network device that the sja1105 switch driver creates (which
is doable).

But the problem I'm trying to solve with the management queue is not
congestion on the master port or inside the switch, but a problem that I
myself have created by putting some skb's in a ring that is finite (and
small) in size: the DSA xmit racing with my xmit worker.

Oh I understood that part, which is why I was wondering if it even made
sense to make use of a particular queue and the flow control that is
offered with that given that this is already quite an ad-hoc solution
and what you proposed seems to do the job alright.

Congestion management on the switch is a much ampler issue that I don't
yet know how to handle. The MACs don't appear to generate pause frames,
and the pause frames that they receive are trapped to the CPU as
link-local traffic (DMAC 01-80-C2-00-00-01) where they are simply
consumed by the master's MAC.

Woah, okay :) I suppose this can be made to work if you accept loading
your host CPU a little bit and have it perform flow control instead of
the switch itself. There is no way to have the switch's internal
buffering automatically deal with pause frames?
-- 
Florian