Re: [PATCH bpf-next v4 1/7] bpf: add bpf_skc_to_mptcp_sock_proto

[Mat Martineau <mathew.j.martineau@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

On Tue, 17 May 2022, Alexei Starovoitov wrote:

> On Mon, May 16, 2022 at 10:26 PM Geliang Tang <geliangtang@gmail.com> wrote:
>>
>> Martin KaFai Lau <kafai@fb.com> 于2022年5月17日周二 09:07写道：
>>>
>>> On Fri, May 13, 2022 at 03:48:21PM -0700, Mat Martineau wrote:
>>> [ ... ]
>>>
>>>> diff --git a/include/net/mptcp.h b/include/net/mptcp.h
>>>> index 8b1afd6f5cc4..2ba09de955c7 100644
>>>> --- a/include/net/mptcp.h
>>>> +++ b/include/net/mptcp.h
>>>> @@ -284,4 +284,10 @@ static inline int mptcpv6_init(void) { return 0; }
>>>>  static inline void mptcpv6_handle_mapped(struct sock *sk, bool mapped) { }
>>>>  #endif
>>>>
>>>> +#if defined(CONFIG_MPTCP) && defined(CONFIG_BPF_SYSCALL)
>>>> +struct mptcp_sock *bpf_mptcp_sock_from_subflow(struct sock *sk);
>>> Can this be inline ?
>>
>> This function can't be inline since it uses struct mptcp_subflow_context.
>>
>> mptcp_subflow_context is defined in net/mptcp/protocol.h, and we don't
>> want to export it to user space in net/mptcp/protocol.h.
>
> The above function can be made static inline in a header file.
> That doesn't automatically expose it to user space.
>

True, it's not a question of userspace exposure. But making this one 
function inline involves a bunch of churn in the (non-BPF) mptcp headers 
that I'd rather avoid. The definitions in protocol.h are there because 
they aren't relevant outside of the mptcp subsystem code.

Does making this one function inline benefit BPF, specifically, in a 
meaningful way? If not, I'd like to leave it as-is.

--
Mat Martineau
Intel