Re: [PATCH net] net: dsa: clear the conduit RX queue on user port receive

[John Macias]

Both findings are right. A revised v2 is prepared with the changes below.

> The commit message says "TX queue selection is unaffected: ..."

That sentence is wrong. Clearing the mapping leaves no RX queue
recorded, so when no socket mapping or XPS map decides, skb_tx_hash()
picks the TX queue of a forwarded flow from the flow hash rather than
the conduit's RX queue number. Some taggers also consume the selected
TX queue: tag_brcm encodes it directly, while tag_ksz, tag_sja1105,
tag_ocelot_8021q, tag_netc and tag_vsc73xx_8021q derive a traffic class
or PCP. Different queues within the same class need not change that
encoded class. With CONFIG_SOCK_RX_QUEUE_MAPPING, packets received through DSA
ports also stop updating sk_rx_queue_mapping, so xps_rxqs no longer
follows the conduit's queue number for those sockets; a mapping the
socket already holds is left as it is.

I kept "not recorded" over recording queue 0. Both make get_rps_cpu()
use the first RX queue's map, but recording 0 would, when nothing else
picks the queue, put every forwarded flow on the first TX queue of its
traffic class. Under QEMU, 16 flows from conduit queue 0 routed out a
4-queue NIC with XPS cleared gave eth1 TX deltas of 800/0/0/1 with
queue 0 recorded and 201/100/350/150 with none recorded (one other
packet is included in each). v2 describes these effects in the
changelog.

> The fix is incomplete because one delivery path in dsa_switch_rcv()
> skips it.

Yes. v2 clears the mapping right after eth_type_trans(), once the
tagger has set skb->dev and before the branch for devices that are not
user ports. With tag_dsa trunk frames delivered to a 2-queue bond, the
unpatched kernel and v1 both hit the WARN_ONCE() and skipped RPS for
queues 1 and 3. With v2, each source-queue group's connected socket
reported CPU4 and the bond warning disappeared. These are observations
of the socket's latest receive CPU, not per-packet CPU attribution;
queue 2's NAPI already ran on CPU4 and does not discriminate.

pw-bot: cr