All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Louis Amas <louis.amas@eho.link>
Cc: stable@vger.kernel.org, kuba@kernel.org,
	Emmanuel Deloget <emmanuel.deloget@eho.link>,
	Marcin Wojtas <mw@semihalf.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>
Subject: Re: [PATCH v5 net 1/1] net: mvpp2: fix XDP rx queues registering
Date: Sun, 12 Dec 2021 14:56:17 +0100	[thread overview]
Message-ID: <YbX/gXr+iV2sGoIO@kroah.com> (raw)
In-Reply-To: <20211210171620.679625-1-louis.amas@eho.link>

On Fri, Dec 10, 2021 at 06:16:20PM +0100, Louis Amas wrote:
> commit a50e659b2a1be14784e80f8492aab177e67c53a2 upstream
> 
> 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 <louis.amas@eho.link>
> Signed-off-by: Emmanuel Deloget <emmanuel.deloget@eho.link>
> Reviewed-by: Marcin Wojtas <mw@semihalf.com>
> Acked-by: John Fastabend <john.fastabend@gmail.com>
> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
> 
> Patch history
> 
> v1 : original submission [1]
> v2 : commit message rework (no change in the patch) [2]
> v3 : commit message rework (no change in the patch) + added Acked-by [3]
> v4 : fix mail corruption by malevolent SMTP + rebase on net/master
> v5 : (this version) add tags back

Now queued up, thanks.

greg k-h

  reply	other threads:[~2021-12-12 13:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10 17:16 [PATCH v5 net 1/1] net: mvpp2: fix XDP rx queues registering Louis Amas
2021-12-12 13:56 ` Greg KH [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-12-07 14:34 Louis Amas
2021-12-09  2:40 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YbX/gXr+iV2sGoIO@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=brouer@redhat.com \
    --cc=emmanuel.deloget@eho.link \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=louis.amas@eho.link \
    --cc=mw@semihalf.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.