[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1492699691.3109.11.camel@sipsolutions.net>
Date: Thu, 20 Apr 2017 16:48:11 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...nel.org>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: __sk_buff.data_end
On Thu, 2017-04-20 at 16:46 +0200, Daniel Borkmann wrote:
> > Hmm. I don't see what "somewhere else" I could possibly have
> > though, given that I want the (kernel-side) context to be "struct
> > sk_buff *" to allow the skb helpers?
>
> I have not enough context on the wireless side, perhaps could be
> somewhere under skb->dev->ieee80211_ptr or so, iff suitable.
I don't think I even have skb->dev assigned at this point :)
> But
> it also really doesn't matter much since this is all transparently
> handled in the kernel, meaning these kind of rewrites can still be
> changed at a later point in time, f.e. if it's only 'u64 boottime_ns'
> right now, that could live directly in the cb[] w/o extra pointer,
> and should that grow to more members, then it could be moved behind
> a pointer later on and it still works as-is from the program point
> of view.
Well, there are 48 bytes in the cb already, so doing this would mean
moving two pointer-sized things out, but yeah - as long as we don't add
everything right now we can keep those things that are available to BPF
in the cb and move something else out.
As long as what I described there with the indirect load works, I'm
fine with this, and I can even do data_end pretty easily then.
johannes
Powered by blists - more mailing lists