quoted

quoted

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 8376bc1c1508..1f7ae4a34d27 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c

@@ -285,14 +285,19 @@ static u16 packet_pick_tx_queue(struct sk_buff *skb)
 {
        struct net_device *dev = skb->dev;
        const struct net_device_ops *ops = dev->netdev_ops;
+       int hint = __packet_pick_tx_queue(dev, skb, NULL);

        u16 queue_index;

+#ifdef CONFIG_XPS
+       skb->sender_cpu = hint + 1;

should this not be raw_smp_processor_id() without the modulo by tx queue count?

yes, here sender_cpu is intentionally 'misused' to keep a behavior more
similar to the unpatched kernel. I'll drop the modulo in the next
iteration.

quoted

also, __packet_pick_tx_queue is a one-line wrapper around
dev_pick_tx_cpu_id. If simplifying the entire wrapper can be removed.

Yes, ideally that will go with a follow-up patch. dev_pick_tx_cpu_id()
is going to loose an argument too, and I'll have to touch this chunk
again. I thought that touching it once would reduce noise.

quoted

quoted

+#endif
+       skb_record_rx_queue(skb, hint);

how is this used in the transmit path?

__netdev_pick_tx() [no XPS conf in place] -> skb_tx_hash() ->
skb_rx_queue_recorded() -> the packet is mapped to (), module tc
mappings.

Ah right.

quoted

quoted

        if (ops->ndo_select_queue) {
                queue_index = ops->ndo_select_queue(dev, skb, NULL,
-                                                   __packet_pick_tx_queue);
+                                                   __netdev_pick_tx);
                queue_index = netdev_cap_txqueue(dev, queue_index);
        } else {
-               queue_index = __packet_pick_tx_queue(dev, skb, NULL);
+               queue_index = __netdev_pick_tx(dev, skb, NULL);
        }

this now duplicates the core of netdev_pick_tx. I wonder if we can
just call that instead of open coding.

either by changing  to take a struct netdev_queue * (it
only has two callers), or by moving the core into a separate
netdev_pick_tx_core (as __netdev_pick_tx is already used).

I tried to minimize the changes in this RFC. I'll go for
netdev_pick_tx_core() in the next iteration, if there are no problem
with an additional EXPORT_SYMBOL_GPL().

I think the original patch may have consciously added a trivial
packet_pick_tx_queue to keep the transmit path as short as possible
for this PACKET_QDISC_BYPASS mode. The more we deduplicate between
that and normal path, the less the feature makes sense.

That said, this particular change seems fine. Even more so if it
allows a follow-up optimization that benefits the common case. Thanks
for answering my questions.

Acked-by: Willem de Bruijn <willemb@google.com>