On Fri, Nov 30, 2018 at 7:41 PM Daniel Borkmann <dan...@iogearbox.net> wrote: > > On 12/01/2018 12:42 AM, Willem de Bruijn wrote: > > On Fri, Nov 30, 2018 at 5:48 PM Song Liu <liu.song....@gmail.com> wrote: > >> > >> On Fri, Nov 30, 2018 at 12:09 PM Willem de Bruijn > >> <willemdebruijn.ker...@gmail.com> wrote: > >>> > >>> From: Petar Penkov <ppen...@google.com> > >>> > >>> The pkt_len field in qdisc_skb_cb stores the skb length as it will > >>> appear on the wire after segmentation. For byte accounting, this value > >>> is more accurate than skb->len. It is computed on entry to the TC > >>> layer, so only valid there. > >>> > >>> Allow read access to this field from BPF tc classifier and action > >>> programs. The implementation is analogous to tc_classid, aside from > >>> restricting to read access. > >>> > >>> Signed-off-by: Petar Penkov <ppen...@google.com> > >>> Signed-off-by: Vlad Dumitrescu <vla...@google.com> > >>> Signed-off-by: Willem de Bruijn <will...@google.com> > >>> --- > >>> include/uapi/linux/bpf.h | 1 + > >>> net/core/filter.c | 16 +++++++++++ > >>> tools/include/uapi/linux/bpf.h | 1 + > >>> tools/testing/selftests/bpf/test_verifier.c | 32 +++++++++++++++++++++ > >>> 4 files changed, 50 insertions(+) > >> > >> Please split this into 3 patches: > >> 1 for include/uapi/linux/bpf.h and filter.c > >> 1 for tools/include/uapi/linux/bpf.h > >> 1 for tools/testing/selftests/bpf/test_verifier.c > >> > >> Other than this > >> Acked-by: Song Liu <songliubrav...@fb.com> > > > > Thanks for the fast review. > > > > I'm happy to resend in three parts, of course, but am curious: what is > > the rationale for splitting this up? > > > > This patch follows the process for commit f11216b24219 ("bpf: add > > skb->tstamp r/w access from tc clsact and cg skb progs"), which went > > in as a single patch just last week. > > Yeah, I think it's fine as is, one small thing I'm wondering though is > given that we now would have both 'skb->len' and 'skb->pkt_len', would > it be more intuitive for a BPF program developer to distinguish the two > by having the latter named e.g. 'skb->wire_len' so it's slightly more > obvious that it's including header size at post-segmentation?
Yes, I actually had considered qdisc_pkt_len to drive home the point that this is derived from, and thus defined by, qdisc_pkt_len_init. But wire_len is a much more intuitive description. I'll send a v2. Thanks!