From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Oskolkov Subject: Re: [PATCH bpf-next 1/2] bpf: add BPF_LWT_ENCAP_IP option to bpf_lwt_push_encap Date: Mon, 3 Dec 2018 08:55:59 -0800 Message-ID: References: <20181129002248.241080-1-posk@google.com> <7c92e102-3e1f-04e3-5387-1616baaa6430@gmail.com> <50f3135e-5e24-d152-b99c-ca86260fbe12@gmail.com> <49ceae53-3f87-44e4-eb8e-3f8bb5151a14@gmail.com> <133be773-6d51-1d19-e5a6-1938accb0592@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: ast@kernel.org, daniel@iogearbox.net, netdev@vger.kernel.org, posk.devel@gmail.com To: David Ahern Return-path: Received: from mail-lj1-f196.google.com ([209.85.208.196]:45944 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726650AbeLCQ4Q (ORCPT ); Mon, 3 Dec 2018 11:56:16 -0500 Received: by mail-lj1-f196.google.com with SMTP id s5-v6so12042991ljd.12 for ; Mon, 03 Dec 2018 08:56:13 -0800 (PST) In-Reply-To: <133be773-6d51-1d19-e5a6-1938accb0592@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: Our case is a bit different - it is more like using the SRH header in IPv6 to route packets via a non-default intermediate hop. But I see your point - I'll expand the patchset to cover IPv6 and the ingress path. On Mon, Dec 3, 2018 at 8:04 AM David Ahern wrote: > > On 11/30/18 5:14 PM, Peter Oskolkov wrote: > > On Fri, Nov 30, 2018 at 3:52 PM David Ahern wrote: > >> > >> On 11/30/18 4:35 PM, Peter Oskolkov wrote: > >>> Thanks, David! This is for egress only, so I'll add an appropriate > >>> check. I'll also address your other comments/concerns in a v2 version > >>> of this patchset. > >> > >> Why are you limiting this to egress only? > > > > I'm focusing on egress because this is a use case that we have and > > understand well, and would like to have a solution for sooner rather > > than later. > > > > Without understanding why anybody would want to do lwt-bpf encap on > > ingress, I don't know, for example, what a good test would look like; > > but I'd be happy to look into a specific ingress use case if you have > > one. > > > > We can not have proliferation of helpers for a lot of one off use cases. > A little thought now makes this helper useful for more than just your 1 > use case. And, IPv6 parity should be a minimal requirement for helpers. > > Based on your route lookup I presume your use case is capturing certain > local traffic, pushing a custom header and sending that packet else > where. The same could be done on the ingress path.