On Tue, Feb 16, 2021 at 2:37 AM Toke Høiland-Jørgensen wrote:
>
> John Fastabend writes:
>
> > Toke Høiland-Jørgensen wrote:
> >> John Fastabend writes:
> >>
> >> >> > However, in libxdp we can solve the original problem in a different
> >> >> > way,
> >> >> > and in fact I already suggested to
On Wed, Feb 17, 2021 at 8:16 AM Magnus Karlsson
wrote:
>
> On Wed, Feb 17, 2021 at 3:26 AM Dan Siemon wrote:
> >
> > On Mon, 2021-02-15 at 22:38 +0100, Toke Høiland-Jørgensen wrote:
> > > The idea is to keep libbpf focused on bpf, and move the AF_XDP stuff
> > > to
> > > libxdp (so the socket stu
On Wed, Feb 17, 2021 at 3:26 AM Dan Siemon wrote:
>
> On Mon, 2021-02-15 at 22:38 +0100, Toke Høiland-Jørgensen wrote:
> > The idea is to keep libbpf focused on bpf, and move the AF_XDP stuff
> > to
> > libxdp (so the socket stuff in xsk.h). We're adding the existing code
> > wholesale, and keepin
On Mon, 2021-02-15 at 22:38 +0100, Toke Høiland-Jørgensen wrote:
> The idea is to keep libbpf focused on bpf, and move the AF_XDP stuff
> to
> libxdp (so the socket stuff in xsk.h). We're adding the existing code
> wholesale, and keeping API compatibility during the move, so all
> that's
> needed i
Maciej Fijalkowski wrote:
> On Tue, Feb 16, 2021 at 11:15:41AM -0800, John Fastabend wrote:
> > Toke Høiland-Jørgensen wrote:
> > > Björn Töpel writes:
> > >
> > > > On 2021-02-15 21:49, John Fastabend wrote:
> > > >> Maciej Fijalkowski wrote:
> > > >>> Currently, if there are multiple xdpsock in
On Tue, Feb 16, 2021 at 11:15:41AM -0800, John Fastabend wrote:
> Toke Høiland-Jørgensen wrote:
> > Björn Töpel writes:
> >
> > > On 2021-02-15 21:49, John Fastabend wrote:
> > >> Maciej Fijalkowski wrote:
> > >>> Currently, if there are multiple xdpsock instances running on a single
> > >>> inte
On Tue, Feb 16, 2021 at 11:27:55AM +0100, Toke Høiland-Jørgensen wrote:
> Maciej Fijalkowski writes:
> >
> > Am I reading this right or you're trying to reject the fix of the long
> > standing issue due to a PR that is not ready yet on a standalone
> > project/library? :P
>
> Haha, no, that is no
On Tue, Feb 16, 2021 at 10:19:17AM -0800, John Fastabend wrote:
> Maciej Fijalkowski wrote:
> > On Mon, Feb 15, 2021 at 12:49:27PM -0800, John Fastabend wrote:
> > > Maciej Fijalkowski wrote:
> > > > Currently, if there are multiple xdpsock instances running on a single
> > > > interface and in cas
Toke Høiland-Jørgensen wrote:
> Björn Töpel writes:
>
> > On 2021-02-15 21:49, John Fastabend wrote:
> >> Maciej Fijalkowski wrote:
> >>> Currently, if there are multiple xdpsock instances running on a single
> >>> interface and in case one of the instances is terminated, the rest of
> >>> them a
Maciej Fijalkowski wrote:
> On Mon, Feb 15, 2021 at 12:49:27PM -0800, John Fastabend wrote:
> > Maciej Fijalkowski wrote:
> > > Currently, if there are multiple xdpsock instances running on a single
> > > interface and in case one of the instances is terminated, the rest of
> > > them are left in a
Björn Töpel writes:
> On 2021-02-15 21:49, John Fastabend wrote:
>> Maciej Fijalkowski wrote:
>>> Currently, if there are multiple xdpsock instances running on a single
>>> interface and in case one of the instances is terminated, the rest of
>>> them are left in an inoperable state due to the fa
John Fastabend writes:
> Toke Høiland-Jørgensen wrote:
>> John Fastabend writes:
>>
>> >> > However, in libxdp we can solve the original problem in a different way,
>> >> > and in fact I already suggested to Magnus that we should do this (see
>> >> > [1]); so one way forward could be to address
Maciej Fijalkowski writes:
> On Mon, Feb 15, 2021 at 08:35:29PM +0100, Toke Høiland-Jørgensen wrote:
>> Björn Töpel writes:
>>
>> > On 2021-02-15 18:07, Toke Høiland-Jørgensen wrote:
>> >> Maciej Fijalkowski writes:
>> >>
>> >>> Currently, if there are multiple xdpsock instances running on a
On 2021-02-16 03:23, Maciej Fijalkowski wrote:
On Mon, Feb 15, 2021 at 04:18:28PM -0800, John Fastabend wrote:
[...]
Once again, is libxdp going to land in th kernel? Still not clear to me.
No, libxdp does not live in the kernel tree.
Björn
[...]
On 2021-02-15 21:49, John Fastabend wrote:
Maciej Fijalkowski wrote:
Currently, if there are multiple xdpsock instances running on a single
interface and in case one of the instances is terminated, the rest of
them are left in an inoperable state due to the fact of unloaded XDP
prog from interfa
On 2021-02-16 03:01, Maciej Fijalkowski wrote:
On Mon, Feb 15, 2021 at 08:35:29PM +0100, Toke Høiland-Jørgensen wrote:
Björn Töpel writes:
[...]
I'd say it's depending on the libbpf 1.0/libxdp merge timeframe. If
we're months ahead, then I'd really like to see this in libbpf until the
merg
On Mon, Feb 15, 2021 at 12:49:27PM -0800, John Fastabend wrote:
> Maciej Fijalkowski wrote:
> > Currently, if there are multiple xdpsock instances running on a single
> > interface and in case one of the instances is terminated, the rest of
> > them are left in an inoperable state due to the fact o
On Mon, Feb 15, 2021 at 04:18:28PM -0800, John Fastabend wrote:
> Toke Høiland-Jørgensen wrote:
> > John Fastabend writes:
> >
> > >> > However, in libxdp we can solve the original problem in a different
> > >> > way,
> > >> > and in fact I already suggested to Magnus that we should do this (see
On Mon, Feb 15, 2021 at 12:22:36PM -0800, John Fastabend wrote:
> Björn Töpel wrote:
> > On 2021-02-15 18:07, Toke Høiland-Jørgensen wrote:
> > > Maciej Fijalkowski writes:
> > >
> > >> Currently, if there are multiple xdpsock instances running on a single
> > >> interface and in case one of the
On Mon, Feb 15, 2021 at 08:35:29PM +0100, Toke Høiland-Jørgensen wrote:
> Björn Töpel writes:
>
> > On 2021-02-15 18:07, Toke Høiland-Jørgensen wrote:
> >> Maciej Fijalkowski writes:
> >>
> >>> Currently, if there are multiple xdpsock instances running on a single
> >>> interface and in case on
Toke Høiland-Jørgensen wrote:
> John Fastabend writes:
>
> >> > However, in libxdp we can solve the original problem in a different way,
> >> > and in fact I already suggested to Magnus that we should do this (see
> >> > [1]); so one way forward could be to address it during the merge in
> >> > l
John Fastabend writes:
>> > However, in libxdp we can solve the original problem in a different way,
>> > and in fact I already suggested to Magnus that we should do this (see
>> > [1]); so one way forward could be to address it during the merge in
>> > libxdp? It should be possible to address th
Maciej Fijalkowski wrote:
> Currently, if there are multiple xdpsock instances running on a single
> interface and in case one of the instances is terminated, the rest of
> them are left in an inoperable state due to the fact of unloaded XDP
> prog from interface.
>
> To address that, step away fr
Björn Töpel wrote:
> On 2021-02-15 18:07, Toke Høiland-Jørgensen wrote:
> > Maciej Fijalkowski writes:
> >
> >> Currently, if there are multiple xdpsock instances running on a single
> >> interface and in case one of the instances is terminated, the rest of
> >> them are left in an inoperable sta
Björn Töpel writes:
> On 2021-02-15 18:07, Toke Høiland-Jørgensen wrote:
>> Maciej Fijalkowski writes:
>>
>>> Currently, if there are multiple xdpsock instances running on a single
>>> interface and in case one of the instances is terminated, the rest of
>>> them are left in an inoperable state
On 2021-02-15 18:07, Toke Høiland-Jørgensen wrote:
Maciej Fijalkowski writes:
Currently, if there are multiple xdpsock instances running on a single
interface and in case one of the instances is terminated, the rest of
them are left in an inoperable state due to the fact of unloaded XDP
prog f
Maciej Fijalkowski writes:
> Currently, if there are multiple xdpsock instances running on a single
> interface and in case one of the instances is terminated, the rest of
> them are left in an inoperable state due to the fact of unloaded XDP
> prog from interface.
>
> To address that, step away
Currently, if there are multiple xdpsock instances running on a single
interface and in case one of the instances is terminated, the rest of
them are left in an inoperable state due to the fact of unloaded XDP
prog from interface.
To address that, step away from setting bpf prog in favour of bpf_l
28 matches
Mail list logo
