Add support for Netkit attachment types

[rcanderson23]

The types BPF_NETKIT_PRIMARY and BPF_NETKIT_PEER are already present in in aya-obj. I took a quick look at what it would take and the existing SchedClassifier APIs potentially make it a little awkward. I am willing to put in some work to get this in if there is any guidance or preference on what the API might look like.

[tamird]

Perhaps you could sketch a proposal.

[rcanderson23]

Regardless of option a new enum for netkit attachments will be created:

pub enum NetkitAttachType {
    Primary,
    Peer,
}

impl NetkitAttachType {
    pub(crate) const fn netkit_attach_type(self) -> bpf_attach_type {
        match self {
            Self::Primary => BPF_NETKIT_PRIMARY,
            Self::Peer => BPF_NETKIT_PEER,
        }
    }
}

Option 1:

Additive methods like attach_netkit() and attach_netkit_with_options() related netkit specific functions. This the smallest change possible and doesn't break current users but has the downside that we have attach() and attach_with_options for tc and tcx and a separate function for netkit specific. This is what I did locally to ensure there was nothing I was missing and it worked.

Option 2:

The attach() call currently hides the attach type based on kernel version. Something like this makes everything explicit but changes the attach apis and requires changes to all the call sites.

pub enum TcNlAttachType {
    Ingress,
    Egress,
    Custom(u32),
}

pub enum TcxAttachType {
    Ingress,
    Egress,
}

pub enum NetkitAttachType {
    Primary,
    Peer,
}
pub enum SchedClassifierAttach {
    Tc {
        attach_type: TcNlAttachType,
        options: NlOptions,
    },
    Tcx {
        attach_type: TcxAttachType,
        order: LinkOrder,
    },
    Netkit {
        attach_type: NetkitAttachType,
        order: LinkOrder,
    },
}

While option 2 is much more involved and a breaking change, it feels more correct as the user knows when they are using netlink vs tcx for attachment instead of hiding it from the user and the three attachments types are explicit.

[tamird]

Option 2 looks reasonable to me.

[rcanderson23]

I am reading through #921 and it seems like @alessandrod wanted to hide the netlink and bpf_link differences with tc program attachments. Is this still a desire? If so, the enum needs to change a little bit.

Looking at cilium/ebpf , they only provide tcx attachment and it is expected to use a different library for netlink tc attachments.

libbpf/libbpf provides separate functions for tc and tcx attachments.