From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexei Starovoitov Subject: Re: [RFC bpf-next 00/11] Add socket lookup support Date: Wed, 16 May 2018 13:04:12 -0700 Message-ID: <20180516200410.utgdgcgxfbd5zu5y@ast-mbp> References: <20180509210709.7201-1-joe@wand.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: daniel@iogearbox.net, netdev , ast@kernel.org, john fastabend , tgraf@suug.ch, Martin KaFai Lau To: Joe Stringer Return-path: Received: from mail-pg0-f46.google.com ([74.125.83.46]:41897 "EHLO mail-pg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751017AbeEPUEP (ORCPT ); Wed, 16 May 2018 16:04:15 -0400 Received: by mail-pg0-f46.google.com with SMTP id w4-v6so746247pgq.8 for ; Wed, 16 May 2018 13:04:15 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Wed, May 16, 2018 at 12:05:06PM -0700, Joe Stringer wrote: > > > > A few open points: > > * Currently, the lookup interface only returns either a valid socket or a NULL > > pointer. This means that if there is any kind of issue with the tuple, such > > as it provides an unsupported protocol number, or the socket can't be found, > > then we are unable to differentiate these cases from one another. One natural > > approach to improve this could be to return an ERR_PTR from the > > bpf_sk_lookup() helper. This would be more complicated but maybe it's > > worthwhile. > > This suggestion would add a lot of complexity, and there's not many > legitimately different error cases. There's: > * Unsupported socket type > * Cannot find netns > * Tuple argument is the wrong size > * Can't find socket > > If we split the helpers into protocol-specific types, the first one > would be addressed. The last one is addressed by returning NULL. It > seems like a reasonable compromise to me to return NULL also in the > middle two cases as well, and rely on the BPF writer to provide valid > arguments. > > > * No ordering is defined between sockets. If the tuple could find multiple > > sockets, then it will arbitrarily return one. It is up to the caller to > > handle this. If we wish to handle this more reliably in future, we could > > encode an ordering preference in the flags field. > > Doesn't need to be addressed with this series, there is scope for > addressing these cases when the use case arises. Thanks for summarizing the conf call discussion. Looking forward to non-rfc patches :)