From: Eyal Birger <eyal.birger@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: netdev@vger.kernel.org, shmulik@metanetworks.com, ast@kernel.org,
daniel@iogearbox.net, fw@strlen.de, steffen.klassert@secunet.com
Subject: Re: [PATCH bpf-next,v2 1/2] bpf: add helper for getting xfrm states
Date: Fri, 20 Apr 2018 06:43:56 +0300 [thread overview]
Message-ID: <20180420064356.7a703a1e@jimi> (raw)
In-Reply-To: <20180418223101.47jl57wrfnqtv6j6@ast-mbp>
Hi,
On Wed, 18 Apr 2018 15:31:03 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Thu, Apr 19, 2018 at 12:58:22AM +0300, Eyal Birger wrote:
> > This commit introduces a helper which allows fetching xfrm state
> > parameters by eBPF programs attached to TC.
> >
> > Prototype:
> > bpf_skb_get_xfrm_state(skb, index, xfrm_state, size, flags)
> >
> > skb: pointer to skb
> > index: the index in the skb xfrm_state secpath array
> > xfrm_state: pointer to 'struct bpf_xfrm_state'
> > size: size of 'struct bpf_xfrm_state'
> > flags: reserved for future extensions
> >
<snip>
> > +#ifdef CONFIG_XFRM
> > +BPF_CALL_5(bpf_skb_get_xfrm_state, struct sk_buff *, skb, u32,
> > index,
> > + struct bpf_xfrm_state *, to, u32, size, u64, flags)
> > +{
> > + const struct sec_path *sp = skb_sec_path(skb);
> > + const struct xfrm_state *x;
> > +
> > + if (!sp || unlikely(index >= sp->len || flags))
> > + goto err_clear;
> > +
> > + x = sp->xvec[index];
> > +
> > + if (unlikely(size != sizeof(struct bpf_xfrm_state)))
> > + goto err_clear;
> > +
> > + to->reqid = x->props.reqid;
> > + to->spi = be32_to_cpu(x->id.spi);
> > + to->family = x->props.family;
> > + if (to->family == AF_INET6) {
> > + memcpy(to->remote_ipv6, x->props.saddr.a6,
> > + sizeof(to->remote_ipv6));
> > + } else {
> > + to->remote_ipv4 = be32_to_cpu(x->props.saddr.a4);
> > + }
>
> that looks inconsistent. Why v4 is cpu endian, but v6 not?
I agree. I followed the reference in bpf_skb_get_tunnel_key().
I can keep v4 in net endianess too.
> Why change endianness of the spi?
I felt it was more consistent with other fields and usually helpful for
programs. I can keep it in network order.
In which case, do you expect it to be typed as __be32 in bpf.h?
(I haven't seen other cases)?
Thanks for your feedback!
next prev parent reply other threads:[~2018-04-20 3:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-18 21:58 [PATCH bpf-next,v2 0/2] bpf: add helper for getting xfrm states Eyal Birger
2018-04-18 21:58 ` [PATCH bpf-next,v2 1/2] " Eyal Birger
2018-04-18 22:31 ` Alexei Starovoitov
2018-04-20 3:43 ` Eyal Birger [this message]
2018-04-23 0:34 ` Alexei Starovoitov
2018-04-24 12:54 ` Daniel Borkmann
2018-04-18 21:58 ` [PATCH bpf-next,v2 2/2] samples/bpf: extend test_tunnel_bpf.sh with xfrm state test Eyal Birger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180420064356.7a703a1e@jimi \
--to=eyal.birger@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=fw@strlen.de \
--cc=netdev@vger.kernel.org \
--cc=shmulik@metanetworks.com \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.