From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Borkmann Subject: Re: [PATCH bpf-next] bpf: Extend the sk_lookup() helper to XDP hookpoint. Date: Thu, 18 Oct 2018 23:20:17 +0200 Message-ID: References: <20181018115029.77ff8e71@ubun> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev , ast@kernel.org, Jesper Brouer , john fastabend To: Joe Stringer , Nitin Hande Return-path: Received: from www62.your-server.de ([213.133.104.62]:60310 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725139AbeJSFXO (ORCPT ); Fri, 19 Oct 2018 01:23:14 -0400 In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 10/18/2018 11:06 PM, Joe Stringer wrote: > On Thu, 18 Oct 2018 at 11:54, Nitin Hande wrote: [...] >> Open Issue >> * The underlying code relies on presence of an skb to find out the >> right sk for the case of REUSEPORT socket option. Since there is >> no skb available at XDP hookpoint, the helper function will return >> the first available sk based off the 5 tuple hash. If the desire >> is to return a particular sk matching reuseport_cb function, please >> suggest way to tackle it, which can be addressed in a future commit. >> Signed-off-by: Nitin Hande > > Thanks Nitin, LGTM overall. > > The REUSEPORT thing suggests that the usage of this helper from XDP > layer may lead to a different socket being selected vs. the equivalent > call at TC hook, or other places where the selection may occur. This > could be a bit counter-intuitive. > > One thought I had to work around this was to introduce a flag, > something like BPF_F_FIND_REUSEPORT_SK_BY_HASH. This flag would > effectively communicate in the API that the bpf_sk_lookup_xxx() > functions will only select a REUSEPORT socket based on the hash and > not by, for example BPF_PROG_TYPE_SK_REUSEPORT programs. The absence > of the flag would support finding REUSEPORT sockets by other > mechanisms (which would be allowed for now from TC hooks but would be > disallowed from XDP, since there's no specific plan to support this). Hmm, given skb is NULL here the only way to lookup the socket in such scenario is based on hash, that is, inet_ehashfn() / inet6_ehashfn(), perhaps alternative is to pass this hash in from XDP itself to the helper so it could be custom selector. Do you have a specific use case on this for XDP (just curious)? Thanks, Daniel