public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@kernel•org>
To: Pavel Vazharov <pavel@x3me•net>, Jakub Kicinski <kuba@kernel•org>
Cc: netdev@vger•kernel.org, Magnus Karlsson <magnus.karlsson@gmail•com>
Subject: Re: Need of advice for XDP sockets on top of the interfaces behind a Linux bonding device
Date: Tue, 30 Jan 2024 15:32:06 +0100	[thread overview]
Message-ID: <87wmrqzyc9.fsf@toke.dk> (raw)
In-Reply-To: <CAJEV1igHVsqmk0ctxb-9gM2+PLs_gvpE1fyZwoASgv+jYXOcmg@mail.gmail.com>

Pavel Vazharov <pavel@x3me•net> writes:

>> On Sat, Jan 27, 2024 at 7:08 AM Pavel Vazharov <pavel@x3me•net> wrote:
>>>
>>> On Sat, Jan 27, 2024 at 6:39 AM Jakub Kicinski <kuba@kernel•org> wrote:
>>> >
>>> > On Sat, 27 Jan 2024 05:58:55 +0200 Pavel Vazharov wrote:
>>> > > > Well, it will be up to your application to ensure that it is not. The
>>> > > > XDP program will run before the stack sees the LACP management traffic,
>>> > > > so you will have to take some measure to ensure that any such management
>>> > > > traffic gets routed to the stack instead of to the DPDK application. My
>>> > > > immediate guess would be that this is the cause of those warnings?
>>> > >
>>> > > Thank you for the response.
>>> > > I already checked the XDP program.
>>> > > It redirects particular pools of IPv4 (TCP or UDP) traffic to the application.
>>> > > Everything else is passed to the Linux kernel.
>>> > > However, I'll check it again. Just to be sure.
>>> >
>>> > What device driver are you using, if you don't mind sharing?
>>> > The pass thru code path may be much less well tested in AF_XDP
>>> > drivers.
>>> These are the kernel version and the drivers for the 3 ports in the
>>> above bonding.
>>> ~# uname -a
>>> Linux 6.3.2 #1 SMP Wed May 17 08:17:50 UTC 2023 x86_64 GNU/Linux
>>> ~# lspci -v | grep -A 16 -e 1b:00.0 -e 3b:00.0 -e 5e:00.0
>>> 1b:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit
>>> SFI/SFP+ Network Connection (rev 01)
>>>        ...
>>>         Kernel driver in use: ixgbe
>>> --
>>> 3b:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit
>>> SFI/SFP+ Network Connection (rev 01)
>>>         ...
>>>         Kernel driver in use: ixgbe
>>> --
>>> 5e:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit
>>> SFI/SFP+ Network Connection (rev 01)
>>>         ...
>>>         Kernel driver in use: ixgbe
>>>
>>> I think they should be well supported, right?
>>> So far, it seems that the present usage scenario should work and the
>>> problem is somewhere in my code.
>>> I'll double check it again and try to simplify everything in order to
>>> pinpoint the problem.
> I've managed to pinpoint that forcing the copying of the packets
> between the kernel and the user space
> (XDP_COPY) fixes the issue with the malformed LACPDUs and the not
> working bonding.

(+Magnus)

Right, okay, that seems to suggest a bug in the internal kernel copying
that happens on XDP_PASS in zero-copy mode. Which would be a driver bug;
any chance you could test with a different driver and see if the same
issue appears there?

-Toke

  reply	other threads:[~2024-01-30 14:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-26 15:54 Need of advice for XDP sockets on top of the interfaces behind a Linux bonding device Pavel Vazharov
2024-01-26 19:28 ` Toke Høiland-Jørgensen
2024-01-27  3:58   ` Pavel Vazharov
2024-01-27  4:39     ` Jakub Kicinski
2024-01-27  5:08       ` Pavel Vazharov
     [not found]         ` <CAJEV1ij=K5Xi5LtpH7SHXLxve+JqMWhimdF50Ddy99G0E9dj_Q@mail.gmail.com>
2024-01-30 13:54           ` Pavel Vazharov
2024-01-30 14:32             ` Toke Høiland-Jørgensen [this message]
2024-01-30 14:40               ` Pavel Vazharov
2024-01-30 14:54                 ` Toke Høiland-Jørgensen
2024-02-05  7:07                   ` Magnus Karlsson
2024-02-07 15:49                     ` Pavel Vazharov
2024-02-07 16:07                       ` Pavel Vazharov
2024-02-07 19:00                       ` Maciej Fijalkowski
2024-02-08 10:59                         ` Pavel Vazharov
2024-02-08 15:47                           ` Pavel Vazharov
2024-02-09  9:03                             ` Pavel Vazharov
2024-02-09 18:37                               ` Maciej Fijalkowski
2024-02-16 15:18                                 ` Maciej Fijalkowski
2024-02-16 17:24                               ` Maciej Fijalkowski
2024-02-19 13:45                                 ` Pavel Vazharov
2024-02-19 14:56                                   ` Maciej Fijalkowski
2024-03-08 10:05                                     ` Pavel Vazharov

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=87wmrqzyc9.fsf@toke.dk \
    --to=toke@kernel$(echo .)org \
    --cc=kuba@kernel$(echo .)org \
    --cc=magnus.karlsson@gmail$(echo .)com \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=pavel@x3me$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox