Marek Majtyka writes:
> On Fri, Feb 12, 2021 at 3:05 AM Alexei Starovoitov
> wrote:
>>
>> On Thu, Feb 11, 2021 at 5:26 PM Jakub Kicinski wrote:
>> >
>> > Perhaps I had seen one too many vendor incompatibility to trust that
>> > adding a driver API without a validation suite will result in somet
On Fri, Feb 12, 2021 at 3:05 AM Alexei Starovoitov
wrote:
>
> On Thu, Feb 11, 2021 at 5:26 PM Jakub Kicinski wrote:
> >
> > Perhaps I had seen one too many vendor incompatibility to trust that
> > adding a driver API without a validation suite will result in something
> > usable in production set
On Thu, Feb 11, 2021 at 5:26 PM Jakub Kicinski wrote:
>
> Perhaps I had seen one too many vendor incompatibility to trust that
> adding a driver API without a validation suite will result in something
> usable in production settings.
I agree with Jakub. I don't see how extra ethtool reporting wil
On Wed, 10 Feb 2021 23:52:39 +0100 Toke Høiland-Jørgensen wrote:
> Jakub Kicinski writes:
> > On Wed, 10 Feb 2021 11:53:53 +0100 Toke Høiland-Jørgensen wrote:
> >> While I do agree that that kind of conformance test would be great, I
> >> don't think it has to hold up this series (the perfect be
Jakub Kicinski writes:
> On Wed, 10 Feb 2021 11:53:53 +0100 Toke Høiland-Jørgensen wrote:
>> >> I am a bit confused now. Did you mean validation tests of those XDP
>> >> flags, which I am working on or some other validation tests?
>> >> What should these tests verify? Can you please elaborate mor
On Wed, 10 Feb 2021 11:53:53 +0100 Toke Høiland-Jørgensen wrote:
> >> I am a bit confused now. Did you mean validation tests of those XDP
> >> flags, which I am working on or some other validation tests?
> >> What should these tests verify? Can you please elaborate more on the
> >> topic, please -
Jakub Kicinski writes:
> On Wed, 3 Feb 2021 13:50:59 +0100 Marek Majtyka wrote:
>> On Tue, Feb 2, 2021 at 8:34 PM Jakub Kicinski wrote:
>> > On Tue, 02 Feb 2021 13:05:34 +0100 Toke Høiland-Jørgensen wrote:
>> > > Awesome! And sorry for not replying straight away - I hate it when I
>> > > send
On Wed, 3 Feb 2021 13:50:59 +0100 Marek Majtyka wrote:
> On Tue, Feb 2, 2021 at 8:34 PM Jakub Kicinski wrote:
> > On Tue, 02 Feb 2021 13:05:34 +0100 Toke Høiland-Jørgensen wrote:
> > > Awesome! And sorry for not replying straight away - I hate it when I
> > > send out something myself and receiv
On Tue, Feb 2, 2021 at 8:34 PM Jakub Kicinski wrote:
>
> On Tue, 02 Feb 2021 13:05:34 +0100 Toke Høiland-Jørgensen wrote:
> > Marek Majtyka writes:
> >
> > > Thanks Toke,
> > >
> > > In fact, I was waiting for a single confirmation, disagreement or
> > > comment. I have it now. As there are no mo
On Tue, 02 Feb 2021 13:05:34 +0100 Toke Høiland-Jørgensen wrote:
> Marek Majtyka writes:
>
> > Thanks Toke,
> >
> > In fact, I was waiting for a single confirmation, disagreement or
> > comment. I have it now. As there are no more comments, I am getting
> > down to work right away.
>
> Awesome
Marek Majtyka writes:
> Thanks Toke,
>
> In fact, I was waiting for a single confirmation, disagreement or
> comment. I have it now. As there are no more comments, I am getting
> down to work right away.
Awesome! And sorry for not replying straight away - I hate it when I
send out something myse
Thanks Toke,
In fact, I was waiting for a single confirmation, disagreement or
comment. I have it now. As there are no more comments, I am getting
down to work right away.
Marek
On Mon, Feb 1, 2021 at 5:16 PM Toke Høiland-Jørgensen wrote:
>
> Marek Majtyka writes:
>
> > I would like to than
Marek Majtyka writes:
> I would like to thank you for your time, comments, nitpicking as well
> as encouraging.
>
> One thing needs clarification I think, that is, that those flags
> describe driver static feature sets - which are read-only. They have
> nothing in common with driver runtime confi
I would like to thank you for your time, comments, nitpicking as well
as encouraging.
One thing needs clarification I think, that is, that those flags
describe driver static feature sets - which are read-only. They have
nothing in common with driver runtime configuration change yet.
Runtime change
On Thu, 2020-12-10 at 14:32 +0100, Jesper Dangaard Brouer wrote:
> On Wed, 9 Dec 2020 08:44:33 -0700
> David Ahern wrote:
>
> > On 12/9/20 4:52 AM, Jesper Dangaard Brouer wrote:
> > > But I have redesigned the ndo_xdp_xmit call to take a bulk of
> > > packets
> > > (up-to 16) so it should not be
On Thu, 2020-12-10 at 08:30 -0700, David Ahern wrote:
> On 12/9/20 11:48 PM, Saeed Mahameed wrote:
> > On Wed, 2020-12-09 at 20:34 -0700, David Ahern wrote:
> > > On 12/9/20 10:15 AM, Saeed Mahameed wrote:
> > > > > My personal experience with this one is mlx5/ConnectX4-LX
> > > > > with a
> > > >
On Thu, 10 Dec 2020 15:14:18 +0100
Magnus Karlsson wrote:
> On Thu, Dec 10, 2020 at 2:32 PM Jesper Dangaard Brouer
> wrote:
> >
> > On Wed, 9 Dec 2020 08:44:33 -0700
> > David Ahern wrote:
> >
> > > On 12/9/20 4:52 AM, Jesper Dangaard Brouer wrote:
> > > > But I have redesigned the ndo_xdp_
On 12/9/20 11:48 PM, Saeed Mahameed wrote:
> On Wed, 2020-12-09 at 20:34 -0700, David Ahern wrote:
>> On 12/9/20 10:15 AM, Saeed Mahameed wrote:
My personal experience with this one is mlx5/ConnectX4-LX with a
limit
>>>
>>> This limit was removed from mlx5
>>> https://patchwork.ozlabs.org
On Thu, Dec 10, 2020 at 2:32 PM Jesper Dangaard Brouer
wrote:
>
> On Wed, 9 Dec 2020 08:44:33 -0700
> David Ahern wrote:
>
> > On 12/9/20 4:52 AM, Jesper Dangaard Brouer wrote:
> > > But I have redesigned the ndo_xdp_xmit call to take a bulk of packets
> > > (up-to 16) so it should not be a probl
On Wed, 9 Dec 2020 08:44:33 -0700
David Ahern wrote:
> On 12/9/20 4:52 AM, Jesper Dangaard Brouer wrote:
> > But I have redesigned the ndo_xdp_xmit call to take a bulk of packets
> > (up-to 16) so it should not be a problem to solve this by sharing
> > TX-queue and talking a lock per 16 packets.
On Wed, 2020-12-09 at 20:34 -0700, David Ahern wrote:
> On 12/9/20 10:15 AM, Saeed Mahameed wrote:
> > > My personal experience with this one is mlx5/ConnectX4-LX with a
> > > limit
> >
> > This limit was removed from mlx5
> > https://patchwork.ozlabs.org/project/netdev/patch/20200107191335.12272-
On 12/9/20 10:15 AM, Saeed Mahameed wrote:
>> My personal experience with this one is mlx5/ConnectX4-LX with a
>> limit
>
> This limit was removed from mlx5
> https://patchwork.ozlabs.org/project/netdev/patch/20200107191335.12272-5-sae...@mellanox.com/
> Note: you still need to use ehttool to incr
On Wed, 2020-12-09 at 08:41 -0700, David Ahern wrote:
> On 12/9/20 4:52 AM, Jesper Dangaard Brouer wrote:
> > > > still load and either share queues across multiple cores or
> > > > restirct
> > > > down to a subset of CPUs.
> > >
> > > And that's the missing piece of logic, I suppose.
> > >
>
On 12/9/20 4:52 AM, Jesper Dangaard Brouer wrote:
> But I have redesigned the ndo_xdp_xmit call to take a bulk of packets
> (up-to 16) so it should not be a problem to solve this by sharing
> TX-queue and talking a lock per 16 packets. I still recommend that,
> for fallback case, you allocated a
On 12/9/20 4:52 AM, Jesper Dangaard Brouer wrote:
>>> still load and either share queues across multiple cores or restirct
>>> down to a subset of CPUs.
>>
>> And that's the missing piece of logic, I suppose.
>>
>>> Do you need 192 cores for a 10gbps nic, probably not.
>>
>> Let's hear from Jes
On Wed, 9 Dec 2020 10:54:54 +0100
Maciej Fijalkowski wrote:
> On Tue, Dec 08, 2020 at 10:03:51PM -0800, John Fastabend wrote:
> > > On Mon, Dec 07, 2020 at 12:52:22PM -0800, John Fastabend wrote:
> > > > Jesper Dangaard Brouer wrote:
> > > > > On Fri, 4 Dec 2020 16:21:08 +0100
> > > > > Danie
John Fastabend writes:
> Toke Høiland-Jørgensen wrote:
>> Jesper Dangaard Brouer writes:
>>
>> > On Mon, 7 Dec 2020 18:01:00 -0700
>> > David Ahern wrote:
>> >
>> >> On 12/7/20 1:52 PM, John Fastabend wrote:
>> >> >>
>> >> >> I think we need to keep XDP_TX action separate, because I think that
On Tue, Dec 08, 2020 at 10:03:51PM -0800, John Fastabend wrote:
> > On Mon, Dec 07, 2020 at 12:52:22PM -0800, John Fastabend wrote:
> > > Jesper Dangaard Brouer wrote:
> > > > On Fri, 4 Dec 2020 16:21:08 +0100
> > > > Daniel Borkmann wrote:
>
> [...] pruning the thread to answer Jesper.
I think
> On Mon, Dec 07, 2020 at 12:52:22PM -0800, John Fastabend wrote:
> > Jesper Dangaard Brouer wrote:
> > > On Fri, 4 Dec 2020 16:21:08 +0100
> > > Daniel Borkmann wrote:
[...] pruning the thread to answer Jesper.
> > >
> > > Use-case(2): Disable XDP_TX on a driver to save hardware TX-queue
> > >
Toke Høiland-Jørgensen wrote:
> Jesper Dangaard Brouer writes:
>
> > On Mon, 7 Dec 2020 18:01:00 -0700
> > David Ahern wrote:
> >
> >> On 12/7/20 1:52 PM, John Fastabend wrote:
> >> >>
> >> >> I think we need to keep XDP_TX action separate, because I think that
> >> >> there are use-cases where
Jesper Dangaard Brouer writes:
> On Mon, 7 Dec 2020 18:01:00 -0700
> David Ahern wrote:
>
>> On 12/7/20 1:52 PM, John Fastabend wrote:
>> >>
>> >> I think we need to keep XDP_TX action separate, because I think that
>> >> there are use-cases where the we want to disable XDP_TX due to end-user
>>
On 12/8/20 10:00 AM, Jesper Dangaard Brouer wrote:
On Mon, 07 Dec 2020 12:52:22 -0800
John Fastabend wrote:
Use-case(1): Cloud-provider want to give customers (running VMs) ability
to load XDP program for DDoS protection (only), but don't want to allow
customer to use XDP_TX (that can implemen
On Mon, 07 Dec 2020 12:52:22 -0800
John Fastabend wrote:
> > Use-case(1): Cloud-provider want to give customers (running VMs) ability
> > to load XDP program for DDoS protection (only), but don't want to allow
> > customer to use XDP_TX (that can implement LB or cheat their VM
> > isolation polic
On Mon, 7 Dec 2020 18:01:00 -0700
David Ahern wrote:
> On 12/7/20 1:52 PM, John Fastabend wrote:
> >>
> >> I think we need to keep XDP_TX action separate, because I think that
> >> there are use-cases where the we want to disable XDP_TX due to end-user
> >> policy or hardware limitations.
> >
On 12/7/20 1:52 PM, John Fastabend wrote:
>>
>> I think we need to keep XDP_TX action separate, because I think that
>> there are use-cases where the we want to disable XDP_TX due to end-user
>> policy or hardware limitations.
>
> How about we discover this at load time though. Meaning if the prog
On Mon, Dec 07, 2020 at 12:52:22PM -0800, John Fastabend wrote:
> Jesper Dangaard Brouer wrote:
> > On Fri, 4 Dec 2020 16:21:08 +0100
> > Daniel Borkmann wrote:
> >
> > > On 12/4/20 1:46 PM, Maciej Fijalkowski wrote:
> > > > On Fri, Dec 04, 2020 at 01:18:31PM +0100, Toke Høiland-Jørgensen wrote:
On Mon, 2020-12-07 at 12:52 -0800, John Fastabend wrote:
> Jesper Dangaard Brouer wrote:
> > On Fri, 4 Dec 2020 16:21:08 +0100
> > Daniel Borkmann wrote:
> >
> > > On 12/4/20 1:46 PM, Maciej Fijalkowski wrote:
> > > > On Fri, Dec 04, 2020 at 01:18:31PM +0100, Toke Høiland-
> > > > Jørgensen wrote
Jesper Dangaard Brouer wrote:
> On Fri, 4 Dec 2020 16:21:08 +0100
> Daniel Borkmann wrote:
>
> > On 12/4/20 1:46 PM, Maciej Fijalkowski wrote:
> > > On Fri, Dec 04, 2020 at 01:18:31PM +0100, Toke Høiland-Jørgensen wrote:
> > >> alar...@gmail.com writes:
> > >>> From: Marek Majtyka
> > >>>
>
On Fri, 4 Dec 2020 16:21:08 +0100
Daniel Borkmann wrote:
> On 12/4/20 1:46 PM, Maciej Fijalkowski wrote:
> > On Fri, Dec 04, 2020 at 01:18:31PM +0100, Toke Høiland-Jørgensen wrote:
> >> alar...@gmail.com writes:
> >>> From: Marek Majtyka
> >>>
> >>> Implement support for checking what kind o
Jesper Dangaard Brouer writes:
> On Fri, 4 Dec 2020 23:19:55 +0100
> Daniel Borkmann wrote:
>
>> On 12/4/20 6:20 PM, Toke Høiland-Jørgensen wrote:
>> > Daniel Borkmann writes:
>> [...]
>> >> We tried to standardize on a minimum guaranteed amount, but unfortunately
>> >> not
>> >> everyone se
Daniel Borkmann writes:
> On 12/4/20 6:20 PM, Toke Høiland-Jørgensen wrote:
>> Daniel Borkmann writes:
> [...]
>>> We tried to standardize on a minimum guaranteed amount, but unfortunately
>>> not
>>> everyone seems to implement it, but I think it would be very useful to query
>>> this from app
On Fri, 4 Dec 2020 23:19:55 +0100
Daniel Borkmann wrote:
> On 12/4/20 6:20 PM, Toke Høiland-Jørgensen wrote:
> > Daniel Borkmann writes:
> [...]
> >> We tried to standardize on a minimum guaranteed amount, but unfortunately
> >> not
> >> everyone seems to implement it, but I think it would be
On 12/4/20 6:20 PM, Toke Høiland-Jørgensen wrote:
Daniel Borkmann writes:
[...]
We tried to standardize on a minimum guaranteed amount, but unfortunately not
everyone seems to implement it, but I think it would be very useful to query
this from application side, for example, consider that an a
Daniel Borkmann writes:
> On 12/4/20 1:46 PM, Maciej Fijalkowski wrote:
>> On Fri, Dec 04, 2020 at 01:18:31PM +0100, Toke Høiland-Jørgensen wrote:
>>> alar...@gmail.com writes:
From: Marek Majtyka
Implement support for checking what kind of xdp functionality a netdev
supports
On 12/4/20 1:46 PM, Maciej Fijalkowski wrote:
On Fri, Dec 04, 2020 at 01:18:31PM +0100, Toke Høiland-Jørgensen wrote:
alar...@gmail.com writes:
From: Marek Majtyka
Implement support for checking what kind of xdp functionality a netdev
supports. Previously, there was no way to do this other th
On Fri, Dec 04, 2020 at 11:28:57AM +0100, alar...@gmail.com wrote:
> From: Marek Majtyka
>
> Implement support for checking what kind of xdp functionality a netdev
> supports. Previously, there was no way to do this other than to try
> to create an AF_XDP socket on the interface or load an XDP pr
On Fri, Dec 04, 2020 at 01:18:31PM +0100, Toke Høiland-Jørgensen wrote:
> alar...@gmail.com writes:
>
> > From: Marek Majtyka
> >
> > Implement support for checking what kind of xdp functionality a netdev
> > supports. Previously, there was no way to do this other than to try
> > to create an AF_
alar...@gmail.com writes:
> From: Marek Majtyka
>
> Implement support for checking what kind of xdp functionality a netdev
> supports. Previously, there was no way to do this other than to try
> to create an AF_XDP socket on the interface or load an XDP program and see
> if it worked. This commit
From: Marek Majtyka
Implement support for checking what kind of xdp functionality a netdev
supports. Previously, there was no way to do this other than to try
to create an AF_XDP socket on the interface or load an XDP program and see
if it worked. This commit changes this by adding a new variable
49 matches
Mail list logo
