All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>,
	"Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Emmanuel Deloget <emmanuel.deloget@eho.link>,
	Louis Amas <louis.amas@eho.link>,
	andrii@kernel.org, ast@kernel.org, bpf@vger.kernel.org,
	daniel@iogearbox.net, davem@davemloft.net, hawk@kernel.org,
	john.fastabend@gmail.com, kafai@fb.com, kpsingh@kernel.org,
	linux-kernel@vger.kernel.org, mw@semihalf.com,
	netdev@vger.kernel.org, songliubraving@fb.com, yhs@fb.com
Subject: Re: [PATCH 1/1] net: mvpp2: fix XDP rx queues registering
Date: Mon, 06 Dec 2021 08:16:06 -0800	[thread overview]
Message-ID: <61ae3746df2f9_88182085b@john.notmuch> (raw)
In-Reply-To: <20211206080337.13fc9ae7@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

Jakub Kicinski wrote:
> On Mon, 6 Dec 2021 15:42:47 +0000 Russell King (Oracle) wrote:
> > On Mon, Dec 06, 2021 at 04:37:20PM +0100, Emmanuel Deloget wrote:
> > > On 10/11/2021 15:41, 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.
> > > > 
> > > > When we register the XDP rx queue information (using
> > > > xdp_rxq_info_reg() in function mvpp2_rxq_init()) we tell them to use
> > > > rxq->id as the queue id. This value iscomputed as:
> > > > rxq->id = port->id * max_rxq_count + queue_id
> > > > 
> > > > where max_rxq_count depends on the device version. In the MB 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.
> > > > 
> > > > This is consistent with the remaining part of the code in
> > > > mvpp2_rxq_init().
> 
> > > Is there any update on this patch ? Without it, XDP only partially work on a
> > > MACCHIATOBin (read: it works on some ports, not on others, as described in
> > > our analysis sent together with the original patch).  
> > 
> > I suspect if you *didn't* thread your updated patch to your previous
> > submission, then it would end up with a separate entry in
> > patchwork.kernel.org,
> 
> Indeed, it's easier to keep track of patches which weren't posted 
> as a reply in a thread, at least for me.
> 
> > and the netdev maintainers will notice that the
> > patch is ready for inclusion, having been reviewed by Marcin.
> 
> In this case I _think_ it was dropped because it didn't apply.
> 
> Please rebase on top of net/master and repost if the changes is still
> needed.

Also I would add the detailed description to the actual commit not below
the "--" lines. Capturing that in the log will be useful for future
reference if we ever hit similar issue here or elsewhere.

Otherwise for patch,

Acked-by: John Fastabend <john.fastabend@gmail.com>

  reply	other threads:[~2021-12-06 16:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-09 10:31 [PATCH] net: mvpp2: fix XDP rx queues registering Louis Amas
2021-11-09 14:44 ` Marcin Wojtas
2021-11-09 17:01   ` Emmanuel Deloget
2021-11-10 14:41     ` [PATCH 1/1] " Louis Amas
2021-12-06 15:37       ` Emmanuel Deloget
2021-12-06 15:42         ` Russell King (Oracle)
2021-12-06 16:03           ` Jakub Kicinski
2021-12-06 16:16             ` John Fastabend [this message]
2021-12-06 16:45               ` Emmanuel Deloget

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=61ae3746df2f9_88182085b@john.notmuch \
    --to=john.fastabend@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=emmanuel.deloget@eho.link \
    --cc=hawk@kernel.org \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=louis.amas@eho.link \
    --cc=mw@semihalf.com \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.com \
    /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.