On 09/01/2024 5:08, Jakub Kicinski wrote:

On Mon, 8 Jan 2024 14:30:54 +0200 Gal Pressman wrote:

quoted

On 05/01/2024 0:50, Jakub Kicinski wrote:

quoted

On Wed, 20 Dec 2023 16:57:16 -0800 Saeed Mahameed wrote:  

quoted

Example for 2 mdevs and 6 channels:
+-------+---------+
| ch ix | mdev ix |
+-------+---------+
|   0   |    0    |
|   1   |    1    |
|   2   |    0    |
|   3   |    1    |
|   4   |    0    |
|   5   |    1    |
+-------+---------+  

Meaning Rx queue 0 goes to PF 0, Rx queue 1 goes to PF 1, etc.?  

Correct.

quoted

Is the user then expected to magic pixie dust the XPS or some such
to get to the right queue?  

I'm confused, how are RX queues related to XPS?

Separate sentence, perhaps I should be more verbose..

Sorry, yes, your understanding is correct.
If a packet is received on RQ 0 then it is from PF 0, RQ 1 came from PF
1, etc. Though this is all from the same wire/port.

You can enable arfs for example, which will make sure that packets that
are destined to a certain CPU will be received by the PF that is closer
to it.

quoted

XPS shouldn't be affected, we just make sure that whatever queue XPS
chose will go out through the "right" PF.

But you said "correct" to queue 0 going to PF 0 and queue 1 to PF 1.
The queue IDs in my question refer to the queue mapping form the stacks
perspective. If user wants to send everything to queue 0 will it use
both PFs?

If all traffic is transmitted through queue 0, it will go out from PF 0
(the PF that is closer to CPU 0 numa).

quoted

So for example, XPS will choose a queue according to the CPU, and the
driver will make sure that packets transmitted from this SQ are going
out through the PF closer to that NUMA.

Sounds like queue 0 is duplicated in both PFs, then?

Depends on how you look at it, each PF has X queues, the netdev has 2X
queues.

quoted

quoted

How is this going to get represented in the recently merged Netlink
queue API?  

Can you share a link please?

commit a90d56049acc45802f67cd7d4c058ac45b1bc26f

Thanks, will take a look.

quoted

All the logic is internal to the driver, so I expect it to be fine, but
I'd like to double check.

Herm, "internal to the driver" is a bit of a landmine. It will be fine
for iperf testing but real users will want to configure the NIC.

What kind of configuration are you thinking of?