On Fri, May 17, 2019 at 8:20 PM Jakub Kicinski
wrote:
>
> On Thu, 16 May 2019 14:37:51 +0200, Magnus Karlsson wrote:
> > Applications
> > method cores irqstxpushrxdrop l2fwd
> > ---
On Thu, 16 May 2019 14:37:51 +0200, Magnus Karlsson wrote:
> Applications
> method cores irqstxpushrxdrop l2fwd
> ---
> r-t-c 2 y 35.9 11.28.6
On Fri, May 17, 2019 at 1:50 AM Samudrala, Sridhar
wrote:
>
> On 5/16/2019 5:37 AM, Magnus Karlsson wrote:
> >
> > After a number of surprises and issues in the driver here are now the
> > first set of results. 64 byte packets at 40Gbit/s line rate. All
> > results in Mpps. Note that I just used m
On 5/16/2019 5:37 AM, Magnus Karlsson wrote:
After a number of surprises and issues in the driver here are now the
first set of results. 64 byte packets at 40Gbit/s line rate. All
results in Mpps. Note that I just used my local system and kernel build
for these numbers so they are not performanc
On Wed, May 8, 2019 at 2:10 PM Magnus Karlsson
wrote:
>
> On Tue, May 7, 2019 at 8:24 PM Alexei Starovoitov
> wrote:
> >
> > On Tue, May 07, 2019 at 01:51:45PM +0200, Magnus Karlsson wrote:
> > > On Mon, May 6, 2019 at 6:33 PM Alexei Starovoitov
> > > wrote:
> > > >
> > > > On Thu, May 02, 2019
On Mon, 13 May 2019 at 22:44, Jonathan Lemon wrote:
>
> Tossing in my .02 cents:
>
>
> I anticipate that most users of AF_XDP will want packet processing
> for a given RX queue occurring on a single core - otherwise we end
> up with cache delays. The usual model is one thread, one socket,
> one c
On 5/13/2019 1:42 PM, Jonathan Lemon wrote:
Tossing in my .02 cents:
I anticipate that most users of AF_XDP will want packet processing
for a given RX queue occurring on a single core - otherwise we end
up with cache delays. The usual model is one thread, one socket,
one core, but this isn't e
Tossing in my .02 cents:
I anticipate that most users of AF_XDP will want packet processing
for a given RX queue occurring on a single core - otherwise we end
up with cache delays. The usual model is one thread, one socket,
one core, but this isn't enforced anywhere in the AF_XDP code and is
up
On Tue, May 7, 2019 at 8:24 PM Alexei Starovoitov
wrote:
>
> On Tue, May 07, 2019 at 01:51:45PM +0200, Magnus Karlsson wrote:
> > On Mon, May 6, 2019 at 6:33 PM Alexei Starovoitov
> > wrote:
> > >
> > > On Thu, May 02, 2019 at 10:39:16AM +0200, Magnus Karlsson wrote:
> > > > This RFC proposes to
On Tue, May 07, 2019 at 01:51:45PM +0200, Magnus Karlsson wrote:
> On Mon, May 6, 2019 at 6:33 PM Alexei Starovoitov
> wrote:
> >
> > On Thu, May 02, 2019 at 10:39:16AM +0200, Magnus Karlsson wrote:
> > > This RFC proposes to add busy-poll support to AF_XDP sockets. With
> > > busy-poll, the drive
On Mon, May 6, 2019 at 6:33 PM Alexei Starovoitov
wrote:
>
> On Thu, May 02, 2019 at 10:39:16AM +0200, Magnus Karlsson wrote:
> > This RFC proposes to add busy-poll support to AF_XDP sockets. With
> > busy-poll, the driver is executed in process context by calling the
> > poll() syscall. The main
On Thu, May 02, 2019 at 10:39:16AM +0200, Magnus Karlsson wrote:
> This RFC proposes to add busy-poll support to AF_XDP sockets. With
> busy-poll, the driver is executed in process context by calling the
> poll() syscall. The main advantage with this is that all processing
> occurs on a single core
This RFC proposes to add busy-poll support to AF_XDP sockets. With
busy-poll, the driver is executed in process context by calling the
poll() syscall. The main advantage with this is that all processing
occurs on a single core. This eliminates the core-to-core cache
transfers that occur between the
13 matches
Mail list logo
