[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250205090958.278ffaff@kernel.org>
Date: Wed, 5 Feb 2025 09:09:58 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Amit Cohen <amcohen@...dia.com>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>, Petr Machata
<petrm@...dia.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Andrew Lunn
<andrew+netdev@...n.ch>, Network Development <netdev@...r.kernel.org>, Ido
Schimmel <idosch@...dia.com>, Alexei Starovoitov <ast@...nel.org>, Daniel
Borkmann <daniel@...earbox.net>, Jesper Dangaard Brouer <hawk@...nel.org>,
John Fastabend <john.fastabend@...il.com>, bpf <bpf@...r.kernel.org>, mlxsw
<mlxsw@...dia.com>
Subject: Re: [PATCH net-next 00/12] mlxsw: Preparations for XDP support
On Tue, 4 Feb 2025 17:26:43 +0000 Amit Cohen wrote:
> > > You're right, most of packets should be handled by HW, XDP is
> > > mainly useful for telemetry.
> >
> > Why skb path is not enough?
>
> We get better packet rates using XDP, this can be useful to redirect
> packets to a server for analysis for example.
TBH I also feel a little ambivalent about adding advanced software
features to mlxsw. You have a dummy device off which you hang the NAPIs,
the page pools, and now the RXQ objects. That already works poorly with
our APIs. How are you going to handle the XDP side? Program per port,
I hope? But the basic fact remains that only fallback traffic goes thru
the XDP program which is not the normal Linux model, routing is after
XDP.
On one hand it'd be great if upstream switch drivers could benefit from
the advanced features. On the other the HW is clearly not capable of
delivering in line with how NICs work, so we're signing up for a stream
of corner cases, bugs and incompatibility. Dunno.
Powered by blists - more mailing lists