From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: [bpf-next v2 8/9] bpf: Provide helper to do forwarding lookups in kernel FIB table Date: Wed, 9 May 2018 15:29:13 -0600 Message-ID: References: <20180504025432.23451-1-dsahern@gmail.com> <20180504025432.23451-9-dsahern@gmail.com> <433c2320-ed9b-446e-6e29-92075f947251@iogearbox.net> <69063df2-8987-b5f1-ced2-b2443139b5a5@gmail.com> <88bd5281-2fa6-41d1-98f3-33c3d4a95674@iogearbox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: davem@davemloft.net, shm@cumulusnetworks.com, roopa@cumulusnetworks.com, brouer@redhat.com, toke@toke.dk, john.fastabend@gmail.com To: Daniel Borkmann , netdev@vger.kernel.org, borkmann@iogearbox.net, ast@kernel.org Return-path: Received: from mail-pl0-f66.google.com ([209.85.160.66]:46963 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964968AbeEIV3R (ORCPT ); Wed, 9 May 2018 17:29:17 -0400 Received: by mail-pl0-f66.google.com with SMTP id 59-v6so5046229plc.13 for ; Wed, 09 May 2018 14:29:16 -0700 (PDT) In-Reply-To: <88bd5281-2fa6-41d1-98f3-33c3d4a95674@iogearbox.net> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 5/9/18 2:44 PM, Daniel Borkmann wrote: > Generally, no objection. However, could we get rid of the two extra includes altogether > to avoid running into any such dependency issue? Right now the only includes we have in > the bpf uapi header is linux/types.h and linux/bpf_common.h (latter has no extra deps > by itself). Both the ETH_ALEN and struct in6_addr are in uapi and therefore never allowed > to change so we can e.g. avoid to use ETH_ALEN and just have the value instead. In the > other places of the header we use __u32 remote_ipv6[4], __u32 src_ip6[4] etc to denote > a v6 address, we could do the same here and should be all good then. I was able to drop the include of linux/in6.h and still use in6_addr. I would prefer to keep in6_addr since it works and avoid the need to add typecasts. As for ETH_ALEN, I could redefine it but it just kicks the can down the road. If if_ether.h is included after bpf.h, it will cause redefinition warnings.