From: Thomas Graf <tgraf@suug.ch>
To: Tom Herbert <tom@herbertland.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
roopa <roopa@cumulusnetworks.com>
Subject: Re: [PATCH net-next 3/4] bpf: BPF for lightweight tunnel encapsulation
Date: Mon, 31 Oct 2016 16:06:40 +0100 [thread overview]
Message-ID: <20161031150640.GC32374@pox.localdomain> (raw)
In-Reply-To: <CALx6S34hHZDdtZgLBZzw-QiOc80tjrLAuAVBDeWRuUonR1MfXA@mail.gmail.com>
On 10/31/16 at 07:17am, Tom Herbert wrote:
> On Mon, Oct 31, 2016 at 5:59 AM, Thomas Graf <tgraf@suug.ch> wrote:
> > Noticed while implementing this: How does ILA ensure that dst_output()
> > is not invoked in a circular manner?
> >
> > dstA->output() -> dstB->otuput() -> dstA->output() -> ...
>
> It doesn't. We'll need to add a check for that. Maybe the rule should
> be that an skbuff is only allowed to hit one LWT route?
I'll add a per cpu variable to do a recursion limit for dst_output()
which callers to possibly recurse can use. ILA can use that as well.
> Another scenario to consider: Suppose someone is doing protocol
> translation like in RFC7915. This is one of operations we'd need with
> ILA or GRE to implement an IPv4 overlay network over IPv6. Would this
> be allowed/supported in LWT BPF?
In lwtunnel_xmit() yes, input and output would not support this right
now. It will need some logic as the orig_input and orig_output would
obviously be expecting the same protocol. This is the reason why the
xmit prog type currently has a wider set of allowed helpers.
next prev parent reply other threads:[~2016-10-31 15:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-30 11:58 [PATCH net-next 0/4] BPF for lightweight tunnel encapsulation Thomas Graf
2016-10-30 11:58 ` [PATCH net-next 1/4] route: Set orig_output when redirecting to lwt on locally generated traffic Thomas Graf
2016-10-30 11:58 ` [PATCH net-next 2/4] route: Set lwtstate for local traffic and cached input dsts Thomas Graf
2016-10-30 11:58 ` [PATCH net-next 3/4] bpf: BPF for lightweight tunnel encapsulation Thomas Graf
2016-10-30 20:34 ` Tom Herbert
2016-10-30 21:47 ` Thomas Graf
2016-10-31 1:28 ` Tom Herbert
2016-10-31 8:19 ` Thomas Graf
2016-10-31 12:59 ` Thomas Graf
2016-10-31 14:17 ` Tom Herbert
2016-10-31 15:06 ` Thomas Graf [this message]
2016-10-31 16:07 ` Tom Herbert
2016-10-31 17:35 ` Thomas Graf
2016-10-30 11:58 ` [PATCH net-next 4/4] bpf: Add samples for LWT-BPF Thomas Graf
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=20161031150640.GC32374@pox.localdomain \
--to=tgraf@suug.ch \
--cc=alexei.starovoitov@gmail.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=roopa@cumulusnetworks.com \
--cc=tom@herbertland.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.