From: Louis Amas <hidden> Date: 2021-12-06 17:22:37
The registration of XDP queue information is incorrect because the
RX queue id we use is invalid. When port->id == 0 it appears to works
as expected yet it's no longer the case when port->id != 0.
The problem arised while using a recent kernel version on the
MACCHIATOBin. This board has several ports:
* eth0 and eth1 are 10Gbps interfaces ; both ports has port->id == 0;
* eth2 is a 1Gbps interface with port->id != 0.
Code from xdp-tutorial (more specifically advanced03-AF_XDP) was used
to test packet capture and injection on all these interfaces. The XDP
kernel was simplified to:
SEC("xdp_sock")
int xdp_sock_prog(struct xdp_md *ctx)
{
int index = ctx->rx_queue_index;
/* A set entry here means that the correspnding queue_id
* has an active AF_XDP socket bound to it. */
if (bpf_map_lookup_elem(&xsks_map, &index))
return bpf_redirect_map(&xsks_map, index, 0);
return XDP_PASS;
}
Starting the program using:
./af_xdp_user -d DEV
Gives the following result:
* eth0 : ok
* eth1 : ok
* eth2 : no capture, no injection
Investigating the issue shows that XDP rx queues for eth2 are wrong:
XDP expects their id to be in the range [0..3] but we found them to be
in the range [32..35].
Trying to force rx queue ids using:
./af_xdp_user -d eth2 -Q 32
fails as expected (we shall not have more than 4 queues).
When we register the XDP rx queue information (using
xdp_rxq_info_reg() in function mvpp2_rxq_init()) we tell it to use
rxq->id as the queue id. This value is computed as:
rxq->id = port->id * max_rxq_count + queue_id
where max_rxq_count depends on the device version. In the MACCHIATOBin
case, this value is 32, meaning that rx queues on eth2 are numbered
from 32 to 35 - there are four of them.
Clearly, this is not the per-port queue id that XDP is expecting:
it wants a value in the range [0..3]. It shall directly use queue_id
which is stored in rxq->logic_rxq -- so let's use that value instead.
rxq->id is left untouched ; its value is indeed valid but it should
not be used in this context.
This is consistent with the remaining part of the code in
mvpp2_rxq_init().
With this change, packet capture is working as expected on all the
MACCHIATOBin ports.
Fixes: b27db2274ba8 ("mvpp2: use page_pool allocator")
Signed-off-by: Louis Amas <redacted>
Signed-off-by: Emmanuel Deloget <redacted>
Reviewed-by: Marcin Wojtas <redacted>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Jesper Dangaard Brouer <redacted>
---
Patch history:
v1 : original submission [1]
v2 : commit message rework (no change in the patch) [2]
v3 : (this version) commit message rework (no change in the patch) + added Acked-by
[1] https://lore.kernel.org/bpf/20211109103101.92382-1-louis.amas@eho.link/
[2] https://lore.kernel.org/bpf/20211110144104.241589-1-louis.amas@eho.link/
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Jakub Kicinski <kuba@kernel.org> Date: 2021-12-06 20:55:23
On Mon, 6 Dec 2021 18:22:19 +0100 Louis Amas wrote:
The registration of XDP queue information is incorrect because the
RX queue id we use is invalid. When port->id == 0 it appears to works
as expected yet it's no longer the case when port->id != 0.
The problem arised while using a recent kernel version on the
MACCHIATOBin. This board has several ports:
* eth0 and eth1 are 10Gbps interfaces ; both ports has port->id == 0;
* eth2 is a 1Gbps interface with port->id != 0.
On Mon, 6 Dec 2021 18:22:19 +0100 Louis Amas wrote:
quoted
The registration of XDP queue information is incorrect because the
RX queue id we use is invalid. When port->id == 0 it appears to works
as expected yet it's no longer the case when port->id != 0.
The problem arised while using a recent kernel version on the
MACCHIATOBin. This board has several ports:
* eth0 and eth1 are 10Gbps interfaces ; both ports has port->id == 0;
* eth2 is a 1Gbps interface with port->id != 0.
Strange...
AFAIK the commit was added on top of net/master (as cloned at approximately 17:30 CET). I'll check with Louis tomorrow morning. We may have messed-up something.
-- Emmanuel Deloget
From: "Russell King (Oracle)" <linux@armlinux.org.uk> Date: 2021-12-06 22:32:33
On Mon, Dec 06, 2021 at 11:14:38PM +0100, Emmanuel Deloget wrote:
Hello,
On 06/12/2021 21:55, Jakub Kicinski wrote:
quoted
On Mon, 6 Dec 2021 18:22:19 +0100 Louis Amas wrote:
quoted
The registration of XDP queue information is incorrect because the
RX queue id we use is invalid. When port->id == 0 it appears to works
as expected yet it's no longer the case when port->id != 0.
The problem arised while using a recent kernel version on the
MACCHIATOBin. This board has several ports:
* eth0 and eth1 are 10Gbps interfaces ; both ports has port->id == 0;
* eth2 is a 1Gbps interface with port->id != 0.
Strange...
AFAIK the commit was added on top of net/master (as cloned at approximately
17:30 CET). I'll check with Louis tomorrow morning. We may have messed-up
something.
The reason it doesn't apply is because something is butchering the
whitespace. Whatever it is, it thinks it knows better than you do,
and is converting the tabs in the patch to a series of space
characters. Your email also appears to be using quoted-printable
encoding.
It looks like you're using git-send-email - and that should be fine.
It also looks like you're sending through a MS Exchange server...
My suspicion would be that the MS Exchange server is re-encoding
to quoted-printable and is butchering the white space, but that's
just a guess. I've no idea what you can do about that.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
The reason it doesn't apply is because something is butchering the
whitespace. Whatever it is, it thinks it knows better than you do,
and is converting the tabs in the patch to a series of space
characters. Your email also appears to be using quoted-printable
encoding.
It looks like you're using git-send-email - and that should be fine.
It also looks like you're sending through a MS Exchange server...
My suspicion would be that the MS Exchange server is re-encoding
to quoted-printable and is butchering the white space, but that's
just a guess. I've no idea what you can do about that.
Oh. That. I would assume you're right, given that we use git-send-email. And that our mail provider is indeed an MS service (smtp.office365.com).
We'll try to figure a way to correctly send the mail tomorrow.
Sorry for the noise, and thanks to everybody for your continuous help.
Best regards,
-- Emmanuel Deloget
Hello,
On 06/12/2021 23:32, Russell King (Oracle) wrote:
On Mon, Dec 06, 2021 at 11:14:38PM +0100, Emmanuel Deloget wrote:
quoted
Hello,
On 06/12/2021 21:55, Jakub Kicinski wrote:
quoted
On Mon, 6 Dec 2021 18:22:19 +0100 Louis Amas wrote:
quoted
The registration of XDP queue information is incorrect because the
RX queue id we use is invalid. When port->id == 0 it appears to works
as expected yet it's no longer the case when port->id != 0.
The problem arised while using a recent kernel version on the
MACCHIATOBin. This board has several ports:
* eth0 and eth1 are 10Gbps interfaces ; both ports has port->id == 0;
* eth2 is a 1Gbps interface with port->id != 0.
Strange...
AFAIK the commit was added on top of net/master (as cloned at approximately
17:30 CET). I'll check with Louis tomorrow morning. We may have messed-up
something.
The reason it doesn't apply is because something is butchering the
whitespace. Whatever it is, it thinks it knows better than you do,
and is converting the tabs in the patch to a series of space
characters. Your email also appears to be using quoted-printable
encoding.
It looks like you're using git-send-email - and that should be fine.
It also looks like you're sending through a MS Exchange server...
My suspicion would be that the MS Exchange server is re-encoding
to quoted-printable and is butchering the white space, but that's
just a guess. I've no idea what you can do about that.
Thanks for you help on this issue. It appears that a configuration hook that was applied on our instance was doing extensive modification of the mail in order to add a banner at the end of the message. We removed it in order to save whitespaces from a gruesome mutilation so it should be ok now.
Louis is sending v4 of the patch as we speak.
Best regards,
-- Emmanuel Deloget