* Re: [PATCH] net: define IPPROTO_SMBDIRECT and SOL_SMBDIRECT constants
[not found] ` <3dd5c950-e3e4-42b8-a40b-f0ee04feb563@redhat.com>
@ 2025-11-27 17:47 ` Stefan Metzmacher
0 siblings, 0 replies; only message in thread
From: Stefan Metzmacher @ 2025-11-27 17:47 UTC (permalink / raw)
To: Paolo Abeni, netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Simon Horman,
Kuniyuki Iwashima, Willem de Bruijn, Steve French, Tom Talpey,
Long Li, Namjae Jeon, Xin Long, linux-kernel, linux-cifs,
samba-technical, linux-rdma, quic
Hi Paolo,
> On 11/26/25 12:14 PM, Stefan Metzmacher wrote:
>> In order to avoid conflicts with the addition of IPPROTO_QUIC,
>> the patch is based on netdev-next/main + the patch adding
>> IPPROTO_QUIC and SOL_QUIC [2].
>>
>> [2]
>> https://lore.kernel.org/quic/0cb58f6fcf35ac988660e42704dae9960744a0a7.1763994509.git.lucien.xin@gmail.com/T/#u
>>
>> As the numbers of IPPROTO_QUIC and SOL_QUIC are already used
>> in various userspace applications it would be good to have
>> this merged to netdev-next/main even if the actual
>> implementation is still waiting for review.
>
> Let me start from here... Why exactly? such applications will not work
> (or at least will not use IPPROTO_QUIC) without the actual protocol
> implementation.
There's the out of tree quic driver, that is used by some people
see https://github.com/lxin/quic.
And Samba 4.23 already uses the specific *_QUIC values,
so it would be good to make sure the values are not used for
something else, by accident.
> Build time issues are much more easily solved with the usual:
>
> #ifndef IPPROTO_*
> #define IPPROTO_
> #endif
Sure, but that still only works reliable if the constants
don't change.
> that the application code should still carry for a bit of time (until
> all the build hosts kernel headers are updated).
The build hosts often don't have current kernel headers
anyway, that's why applications have the hard coded (at least fallback values).
But a host might have a newer kernel (or out of tree module)
at runtime, which would allow the application to use the feature.
> The above considerations also apply to this patch. What is the net
> benefit? Why something like the above preprocessor's macros are not enough?
It's mainly to have the constants reserved in order to avoid collisions
at runtime.
And in the current case also the merge conflict between the two patchsets,
that's another why I thought it would be good to the _QUIC patch already
accepted.
> We need at least to see the paired implementation to accept this patch,
I hope to post the first part of the _SMBDIRECT socket code next
week, it's already working for the in kernel users cifs.ko and ksmbd.ko,
but I want to split the relatively large commit into smaller chunks,
for better review, the current state consists of the top 3 commits of
https://git.samba.org/?p=metze/linux/wip.git;a=shortlog;h=refs/heads/master-ipproto-smbdirect-v0.5
1. the addition of the socket layer above the existing code, for in kernel use only
2. change cifs.ko to use it
3. change ksmbd.ko to use it.
Opening it for userspace will be developed in the next weeks.
> and I personally think it would be better to let the IPPROTO definition
> and the actual implementation land together.
In general I'd agree with you, I'm fine with deferring this patch
a bit and will cope if the _QUIC patch is also deferred.
Anyway thanks for the feedback!
metze
^ permalink raw reply [flat|nested] only message in thread