tc: add TC filter for BPF/TC_BPF_*

[ver-nyan]

Add TC option for BPF filter.
Also adds the hex crate for deserializing bytes into hex formatted string for parsing the BPF program tag.

WIP, missing tests which im working on, but verified manually that it's at least deserializing correctly which is my usecase for Netflix/bpftop#190.
This is my first time actually working with netlink internals, so apologies my understanding is off. :)

Some question i have:

1. TCA_BPF_FLAGS_GEN attribute uses the same TCA_CLS_FLAGS_* flags defined in u32_flags.rs file, so it's currently a wrapper of TcU32OptionFlags. ref link

   In the kernel code, it looks like flower (TCA_FLOWER_FLAGS ref link) & matchall (TCA_MATCHALL_FLAGS ref link) also use the same flags (so far i've only found them in conjunction with tc_flags_valid()).

   I was wondering if the bitflag TcU32OptionFlags should be renamed to something more generic, like TcaFlags. This would end up breaking API tho :/

[gemini-code-assist]

Summary of Changes

Hello @ver-nyan, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request extends the tc netlink packet types to include comprehensive support for BPF filters. It introduces new data structures and parsing logic for BPF-specific attributes, integrates them into the broader tc option handling, and adds a new dependency for hexadecimal string conversion. The primary goal is to enable the configuration and deserialization of BPF filters within the netlink ecosystem.

Highlights

• BPF Filter Support: Introduced a new TC filter type for BPF (Berkeley Packet Filter) programs, enabling the configuration and management of BPF filters via netlink.
• New hex Crate Dependency: Added the hex crate to Cargo.toml to facilitate the deserialization of byte arrays into hex-formatted strings, specifically for parsing BPF program tags.
• Modular BPF Filter Implementation: Created a dedicated module src/tc/filters/bpf.rs to encapsulate the data structures and parsing logic for BPF filter options, including TcFilterBpf and TcFilterBpfOption.
• Integration with TC Options: Integrated the new BPF filter options into the existing TcOption enum and its associated Nla and Parseable trait implementations, allowing tc messages to handle BPF-specific attributes.
• Flag Reusability Question: The author raised a question regarding the generic usage of TcU32OptionFlags by TCA_BPF_FLAGS_GEN and other filters (flower, matchall), suggesting a potential rename to TcaFlags for better generality, while acknowledging it would be an API-breaking change.

Changelog

• Cargo.toml
  • Added hex = "0.4.3" to the [dependencies] section.
• src/tc/filters/bpf.rs
  • New file created to define TcFilterBpf and TcFilterBpfOption.
  • Defines constants for BPF filter NLA kinds (e.g., TCA_BPF_CLASSID, TCA_BPF_FD, TCA_BPF_TAG).
  • Implements Nla trait for TcFilterBpfOption to handle value length, kind, and emission.
  • Implements Parseable trait for TcFilterBpfOption to parse various BPF attributes, including using hex::encode for TCA_BPF_TAG.
• src/tc/filters/mod.rs
  • Added mod bpf; to include the new BPF filter module.
  • Exported TcFilterBpf, TcFilterBpfOption, and TCA_BPF_FLAG_ACT_DIRECT from the bpf module.
• src/tc/mod.rs
  • Re-exported TcFilterBpf, TcFilterBpfOption, and TCA_BPF_FLAG_ACT_DIRECT to make them accessible at the top level of the tc module.
• src/tc/options.rs
  • Imported TcFilterBpf and TcFilterBpfOption.
  • Added a new variant Bpf(TcFilterBpfOption) to the TcOption enum.
  • Updated value_len, emit_value, and kind methods for TcOption to correctly handle the new Bpf variant.
  • Modified the parse method for TcOption to recognize TcFilterBpf::KIND and parse it as TcFilterBpfOption.
  • Included TcFilterBpf::KIND in the list of kinds that require iterating through NLA buffers for parsing.

Activity

• The author has manually verified that deserialization is working correctly, which is crucial for their use case related to bpftop/issues/190.
• The pull request is currently marked as Work In Progress (WIP), with tests still needing to be added.
• The author noted this is their first time working with netlink internals and expressed humility regarding their understanding.
• A specific question was raised about the potential renaming of TcU32OptionFlags to a more generic TcaFlags due to its shared usage across multiple TC filter types, acknowledging it would be an API-breaking change.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request adds support for BPF TC filters, which is a great addition. The implementation mostly follows the existing patterns in the crate. I've found one critical issue with the handling of TCA_BPF_TAG which causes incorrect serialization. I've left a detailed comment with a suggested fix. Once that is addressed, this should be good to go.

Regarding your question about renaming TcU32OptionFlags: renaming it to something more generic like TcaFlags makes sense given its use in other filters like flower and now bpf. However, as you noted, it would be a breaking API change. It might be a good idea to do this in a future major version bump. For this PR, reusing TcU32OptionFlags is a reasonable approach.

[cathay4t]

Could you explains why we introduce new dependency on hex? Just for fancy ProgTag(String)?

[ver-nyan]

Could you explains why we introduce new dependency on hex? Just for fancy ProgTag(String)?

I haven't updated it in here yet, but I ended up changing it ProgTag([u8; BPF_TAG_SIZE]) to keep it transparent with how the kernel defines it. It'll be updated here once tests are up. 👍

The program tag itself is a hash of the bpf program, the format can be left up to the user.

[ver-nyan]

/gemini review

[gemini-code-assist]

Code Review

This pull request does a great job of adding support for BPF TC filters, following the existing patterns in the crate. The new test case is also very helpful for verifying the implementation.

I found a small issue in the test data for TCA_BPF_NAME where the NLA length is incorrect, which would cause the test to fail. I've left a specific comment with a suggested fix.

Regarding your question about renaming TcU32OptionFlags: I agree that the name is a bit misleading now that it's used by multiple filter types. Renaming it to something more generic like TcClassifierFlags would improve clarity and maintainability. Since it's a breaking change, it's good to consider it carefully, but this PR seems like a good opportunity to do it, as you're touching related code.

Overall, great work!

[cathay4t]

Looks good to me. Just a small lint.