Sebastian Andrzej Siewior wrote:

On 2026-03-04 10:56:16 [-0500], Willem de Bruijn wrote:

quoted

Sebastian Andrzej Siewior wrote:

quoted

Would it be okay if I occupy three bits in sk_buff which look unused?

Have you looked into using skb_extensions?

Yes. I would have allocate memory via __skb_ext_alloc() and attach it to
the skb via __skb_ext_set(). That would on receive and while sending
(via af_packet).
Looking at the current allocations as of skb_ext_type_len, they all need
a bit of memory, the smallest is mctp_flow with just a pointer the other
are a fair amount larger. For the three bits, I was hoping to avoid it.

But this is not a performance sensitive path, right? Nor is it very
complicated to add?

I understand your preference. It's just that if every protocol and
feature, let alone their cross-product, adds a few bits to struct
sk_buff, it grows to become unmangeable. A classic tragedy of the
commons. For this reason pushback is common.

Devil's advocate, an alternative would be to add a few bits, then
maybe union them so that other users can use the same bits as long
as their code does not overlaps. This quickly becomes hard to analyze
for correctness. In a sense skb extensions resolved some of this.

That said, happy to hear other opinions or implementation concerns
that I may have underappreciated, e.g., it may not address the HSR
specific needs for AF_PACKET.