On 03/21, Alexei Starovoitov wrote:
> On Thu, Mar 21, 2019 at 9:13 AM Willem de Bruijn
> wrote:
> >
> > On Thu, Mar 21, 2019 at 12:01 PM Alexei Starovoitov
> > wrote:
> > >
> > > On Thu, Mar 21, 2019 at 08:44:33AM -0700, Stanislav Fomichev wrote:
> > > >
> > > > If we can agree that we switch eve
On Thu, Mar 21, 2019 at 9:13 AM Willem de Bruijn
wrote:
>
> On Thu, Mar 21, 2019 at 12:01 PM Alexei Starovoitov
> wrote:
> >
> > On Thu, Mar 21, 2019 at 08:44:33AM -0700, Stanislav Fomichev wrote:
> > >
> > > If we can agree that we switch everything to xpd-like, do we deprecate the
> > > skb-one
On Thu, Mar 21, 2019 at 12:01 PM Alexei Starovoitov
wrote:
>
> On Thu, Mar 21, 2019 at 08:44:33AM -0700, Stanislav Fomichev wrote:
> >
> > If we can agree that we switch everything to xpd-like, do we deprecate the
> > skb-one?
>
> This whole discussion that have been going on for long time is an i
On Thu, Mar 21, 2019 at 08:44:33AM -0700, Stanislav Fomichev wrote:
>
> If we can agree that we switch everything to xpd-like, do we deprecate the
> skb-one?
This whole discussion that have been going on for long time is an indication
that initial bpf flow dissector concept was not thought throug
On 03/21, Willem de Bruijn wrote:
> On Thu, Mar 21, 2019 at 12:45 AM Eric Dumazet wrote:
> >
> >
> >
> > On 03/20/2019 08:39 PM, Alexei Starovoitov wrote:
> >
> > > I think you need to convince Dave and Eric that
> > > above surgery is necessary to do the hack in patch 6 with
> > > +static DEFINE_
On Thu, Mar 21, 2019 at 12:45 AM Eric Dumazet wrote:
>
>
>
> On 03/20/2019 08:39 PM, Alexei Starovoitov wrote:
>
> > I think you need to convince Dave and Eric that
> > above surgery is necessary to do the hack in patch 6 with
> > +static DEFINE_PER_CPU(struct sk_buff, bpf_flow_skb);
> >
>
> Yes,
On 03/20/2019 08:39 PM, Alexei Starovoitov wrote:
> I think you need to convince Dave and Eric that
> above surgery is necessary to do the hack in patch 6 with
> +static DEFINE_PER_CPU(struct sk_buff, bpf_flow_skb);
>
Yes, this is a huge code churn.
Honestly I believe we are going too far in
On Tue, Mar 19, 2019 at 03:19:40PM -0700, Stanislav Fomichev wrote:
> __init_skb is essentially a version of __build_skb which accepts skb as
> an argument (instead of doing kmem_cache_alloc to allocate it).
>
> __init_skb_shinfo initializes shinfo.
>
> __init_skb_data initializes skb data pointe
__init_skb is essentially a version of __build_skb which accepts skb as
an argument (instead of doing kmem_cache_alloc to allocate it).
__init_skb_shinfo initializes shinfo.
__init_skb_data initializes skb data pointers.
No functional changes.
Signed-off-by: Stanislav Fomichev
---
include/lin
