Re: [PATCH net-next 3/4] net/smc: Introduce smc_bpf_ops

D. Wythe
2024-10-29T08:53:42Z

On 10/26/24 2:30 AM, Martin KaFai Lau wrote:
> On 10/25/24 4:05 AM, D. Wythe wrote:
>> Our main concern is to avoid introducing kfuncs as much as possible. For our subsystem, we might
>> need to maintain it in a way that maintains a uapi, as we certainly have user applications
>> depending on it.
>
> The smc_bpf_ops can read/write the tp and ireq. In patch 4, there is 'tp->syn_smc = 1'. I assume the
> real bpf prog will read something from the tp to make the decision also. Note that tp/ireq is also
> not in the uapi but the CO-RE can help in case the tp->syn_smc bool is moved around.
>
> From looking at the selftest in patch 4 again, I think all it needs is for the bpf prog (i.e. the
> ops) to return a bool instead of allowing the bpf prog to write or call a kfunc to change the tp/ireq.
>

Hi Martin,

At the beginning, I did modify it by returning values, but later I wanted to make this ops more
universal, so I considered influencing the behavior by modifying the tp without returning any value.
But considering we currently do not have any other needs, perhaps modifying it by returning a value
would be more appropriate.

And If that's the case, we won't need to add new prog parameters to the struct_access anymore. I'll
try this in the next series.

Thanks,
D. Wythe