On Thu, 2013-12-05 at 18:28 +0100, Michal Sekletár wrote:

On Fri, Nov 29, 2013 at 3:13 PM, Daniel Borkmann [off-list ref] wrote:

quoted

On 11/28/2013 06:31 PM, Eric Dumazet wrote:

quoted

On Thu, 2013-11-28 at 12:57 +0100, Michal Sekletar wrote:

quoted

+enum {
+       BPF_ANC_FLAG_PROTOCOL         = (1 << 0),
+       BPF_ANC_FLAG_PKTTYPE          = (1 << 1),
+       BPF_ANC_FLAG_IFINDEX          = (1 << 2),
+       BPF_ANC_FLAG_NLATTR           = (1 << 3),
+       BPF_ANC_FLAG_NLATTR_NEST      = (1 << 4),
+       BPF_ANC_FLAG_MARK             = (1 << 5),
+       BPF_ANC_FLAG_QUEUE            = (1 << 6),
+       BPF_ANC_FLAG_HATYPE           = (1 << 7),
+       BPF_ANC_FLAG_RXHASH           = (1 << 8),
+       BPF_ANC_FLAG_CPU              = (1 << 9),
+       BPF_ANC_FLAG_ALU_XOR_X        = (1 << 10),
+       BPF_ANC_FLAG_SECCOMP_LD_W     = (1 << 11),
+       BPF_ANC_FLAG_VLAN_TAG         = (1 << 12),
+       BPF_ANC_FLAG_VLAN_TAG_PRESENT = (1 << 13),
+       BPF_ANC_FLAG_PAY_OFFSET       = (1 << 14),
+};
+

Why spending 15 bits (out of 32), for all these extensions ?

It seems a single one should be enough.

I do not think we will ever remove one of these extension.

Agreed, this will just cripple of us adding other extensions in
terms of uapi. I assume there won't be so much more extensions,
but it's of course hard to predict the future. ;-)

Not sure I follow. Can you please elaborate on the explanation. Please
bare with me this is my first kernel patch submission.

if SO_BPF_EXTENSIONS is supported, than you can assume that all current
extensions are supported.

No need to consume one bit per feature, as all these features wont ever
disappear from linux.