Thanks Ben & Dave. A question though - which of the following
is preferable for the macvtap driver:

1. Calculate flow and use that to find a queue; or
2. First check if skb_rx_queue_recorded is true and if so use
    that; otherwise calculate the flow as in #1.

I guess #1 is better, since packets for a single flow will go to the
same queue even if they arrive on different rxqs of a mq driver.
But I want to make sure.

Thanks,

- KK

David Miller [off-list ref] wrote on 08/01/2010 01:04:06 PM:

David Miller [off-list ref]
08/01/2010 01:04 PM

To

bhutchings@solarflare.com

cc

Krishna Kumar2/India/IBM@IBMIN, arnd@arndb.de,
netdev@vger.kernel.org, mst@redhat.com

Subject

Re: [PATCH] Multiqueue macvtap driver

From: Ben Hutchings <redacted>
Date: Sat, 31 Jul 2010 20:18:27 +0100

quoted

On Sat, 2010-07-31 at 19:27 +0530, Krishna Kumar wrote:
[...]

quoted

@@ -136,39 +158,68 @@ static void macvtap_put_queue(struct mac
 }

 /*
- * Since we only support one queue, just dereference the pointer.
+ * Select a queue based on the rxq of the device on which this packet
+ * arrived. If the incoming device is not mq, then use our cpu number
+ * to select a queue. vlan->numvtaps is cached in case it changes
+ * during the execution of this function.
  */

[...]

This can result in reordering if a single-queue device's RX interrupt's
CPU affinity is changed.  We generally try to avoid that.  You should
really use or generate a flow hash.  There is code for this in
net/core/dev.c:get_rps_cpu() which could be factored out into a

separate

quoted

function.

Agreed.