From: Jesper Dangaard Brouer <brouer@redhat.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH intel-net] i40e: fix broken XDP support
Date: Thu, 29 Apr 2021 11:10:56 +0200 [thread overview]
Message-ID: <20210429111056.2174ee76@carbon> (raw)
In-Reply-To: <20210426111401.28369-1-magnus.karlsson@gmail.com>
Hi Tony, (+ Kuba and DaveM),
What is the status on this patch[2] that fixes a crash[1] for i40e driver?
I'm getting offlist and internal IRC questions to why i40e doesn't
work, and I noticed that it seems this have not been applied.
I don't see it in net-next or net tree... would it make sense to route
this via DaveM, or does it depend on the other fixes for i40e.
[1] https://lore.kernel.org/netdev/20210422170508.22c58226 at carbon/
[2] https://patchwork.kernel.org/project/netdevbpf/patch/20210426111401.28369-1-magnus.karlsson at gmail.com/
(top-post)
On Mon, 26 Apr 2021 13:14:01 +0200
Magnus Karlsson <magnus.karlsson@gmail.com> wrote:
> From: Magnus Karlsson <magnus.karlsson@intel.com>
>
> Commit 12738ac4754e ("i40e: Fix sparse errors in i40e_txrx.c") broke
> XDP support in the i40e driver. That commit was fixing a sparse error
> in the code by introducing a new variable xdp_res instead of
> overloading this into the skb pointer. The problem is that the code
> later uses the skb pointer in if statements and these where not
> extended to also test for the new xdp_res variable. Fix this by adding
> the correct tests for xdp_res in these places.
>
> The skb pointer was used to store the result of the XDP program by
> overloading the results in the errror pointer
> ERR_PTR(-result). Therefore, the allocation failure test that used to
> only test for !skb now need to be extended to also consider !xdp_res.
>
> i40e_cleanup_headers() had a check that based on the skb value being
> an error pointer, i.e. a result from the XDP program != XDP_PASS, and
> if so start to process a new packet immediately, instead of populating
> skb fields and sending the skb to the stack. This check is not needed
> anymore, since we have added an explicit test for xdp_res being set
> and if so just do continue to pick the next packet from the NIC.
>
> v1 -> v2:
>
> * Improved commit message.
>
> * Restored the xdp_res = 0 initialization to its original place
> outside the per-packet loop. The original reason to move it inside
> the loop was that it was only initialized inside the loop code if
> skb was not set. But as skb can only be non-null if we have packets
> consisting of multiple frames (skb is set for all frames except the
> last one in a packet) and when this is true XDP cannot be active, so
> this does not matter. xdp_res == 0 is the same as I40E_XDP_PASS
> which is the default action if XDP is not active and it is then true
> for every single packet in this case.
>
> Fixes: 12738ac4754e ("i40e: Fix sparse errors in i40e_txrx.c")
> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Tested-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Reported-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
WARNING: multiple messages have this Message-ID (diff)
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Magnus Karlsson <magnus.karlsson@gmail.com>
Cc: magnus.karlsson@intel.com, intel-wired-lan@lists.osuosl.org,
anthony.l.nguyen@intel.com, maciej.fijalkowski@intel.com,
netdev@vger.kernel.org, brouer@redhat.com,
Jakub Kicinski <kuba@kernel.org>,
David Miller <davem@davemloft.net>,
Hangbin Liu <haliu@redhat.com>
Subject: Re: [PATCH intel-net] i40e: fix broken XDP support
Date: Thu, 29 Apr 2021 11:10:56 +0200 [thread overview]
Message-ID: <20210429111056.2174ee76@carbon> (raw)
In-Reply-To: <20210426111401.28369-1-magnus.karlsson@gmail.com>
Hi Tony, (+ Kuba and DaveM),
What is the status on this patch[2] that fixes a crash[1] for i40e driver?
I'm getting offlist and internal IRC questions to why i40e doesn't
work, and I noticed that it seems this have not been applied.
I don't see it in net-next or net tree... would it make sense to route
this via DaveM, or does it depend on the other fixes for i40e.
[1] https://lore.kernel.org/netdev/20210422170508.22c58226@carbon/
[2] https://patchwork.kernel.org/project/netdevbpf/patch/20210426111401.28369-1-magnus.karlsson@gmail.com/
(top-post)
On Mon, 26 Apr 2021 13:14:01 +0200
Magnus Karlsson <magnus.karlsson@gmail.com> wrote:
> From: Magnus Karlsson <magnus.karlsson@intel.com>
>
> Commit 12738ac4754e ("i40e: Fix sparse errors in i40e_txrx.c") broke
> XDP support in the i40e driver. That commit was fixing a sparse error
> in the code by introducing a new variable xdp_res instead of
> overloading this into the skb pointer. The problem is that the code
> later uses the skb pointer in if statements and these where not
> extended to also test for the new xdp_res variable. Fix this by adding
> the correct tests for xdp_res in these places.
>
> The skb pointer was used to store the result of the XDP program by
> overloading the results in the errror pointer
> ERR_PTR(-result). Therefore, the allocation failure test that used to
> only test for !skb now need to be extended to also consider !xdp_res.
>
> i40e_cleanup_headers() had a check that based on the skb value being
> an error pointer, i.e. a result from the XDP program != XDP_PASS, and
> if so start to process a new packet immediately, instead of populating
> skb fields and sending the skb to the stack. This check is not needed
> anymore, since we have added an explicit test for xdp_res being set
> and if so just do continue to pick the next packet from the NIC.
>
> v1 -> v2:
>
> * Improved commit message.
>
> * Restored the xdp_res = 0 initialization to its original place
> outside the per-packet loop. The original reason to move it inside
> the loop was that it was only initialized inside the loop code if
> skb was not set. But as skb can only be non-null if we have packets
> consisting of multiple frames (skb is set for all frames except the
> last one in a packet) and when this is true XDP cannot be active, so
> this does not matter. xdp_res == 0 is the same as I40E_XDP_PASS
> which is the default action if XDP is not active and it is then true
> for every single packet in this case.
>
> Fixes: 12738ac4754e ("i40e: Fix sparse errors in i40e_txrx.c")
> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Tested-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Reported-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2021-04-29 9:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-26 11:14 [Intel-wired-lan] [PATCH intel-net] i40e: fix broken XDP support Magnus Karlsson
2021-04-26 11:14 ` Magnus Karlsson
2021-04-29 9:10 ` Jesper Dangaard Brouer [this message]
2021-04-29 9:10 ` Jesper Dangaard Brouer
2021-04-29 16:15 ` [Intel-wired-lan] " Nguyen, Anthony L
2021-04-29 16:15 ` Nguyen, Anthony L
-- strict thread matches above, loose matches on Subject: below --
2021-04-23 9:59 [Intel-wired-lan] " Magnus Karlsson
2021-04-23 11:04 ` Jesper Dangaard Brouer
2021-04-23 11:49 ` Maciej Fijalkowski
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=20210429111056.2174ee76@carbon \
--to=brouer@redhat.com \
--cc=intel-wired-lan@osuosl.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.