-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support IFLA_VRF_PORT_TABLE attribute #98
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #98 +/- ##
==========================================
- Coverage 63.97% 63.94% -0.04%
==========================================
Files 140 140
Lines 8617 8528 -89
==========================================
- Hits 5513 5453 -60
+ Misses 3104 3075 -29 ☔ View full report in Codecov by Sentry. |
The clippy failure is due to |
@cathay4t would you mind reviewing this? |
62d4fa3
to
f71ea1d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks good to me. But I would like to see a unit test case parsing and emitting Vec captured on real VRF port. I have document on how to capture netlink message in https://github.com/rust-netlink/netlink-packet-route/blob/main/README.md
f71ea1d
to
d86627c
Compare
@cathay4t I added a test. Note that we might have a couple problemactic attributes when emitting packets, but that doesn't seem to be related to my changes, and I really don't have time to investigate further at the moment unfortunately. See the commented out part of the test. |
d86627c
to
55dd297
Compare
@cathay4t are you ok with merging this? |
Links that belong to a VRF carry the VRF table ID in the link info. For a VRF link we already had these attributes: ``` LinkInfo([Kind(Vrf), Data(Vrf([TableId(10)]))]) ``` For ports attached to a VRF we now have: ``` LinkInfo([Kind(Veth), PortKind(Vrf), PortData(VrfPort([TableId(10)]))]) ``` This tells us that this veth interface belong to the VRF with table ID 10.
Note that I had to derive `Default` on a couple structs to make the test manageable. Also, I noticed that the packet we emit does not 100% matches the packet emitted by the kernel.
55dd297
to
a822400
Compare
Your kernel support That is not related to your patch. I will fix it later. |
#119 created for the FIXME. |
Links that belong to a VRF carry the VRF table ID in the link info. For a VRF link we already had these attributes:
For ports attached to a VRF we now have:
This tells us that this veth interface belong to the VRF with table ID 10.
To test this:
Ref: https://github.com/torvalds/linux/blob/f2e367d6ad3bdc527c2b14e759c2f010d6b2b7a1/drivers/net/vrf.c#L1797