if_infiniband: Support BPF write for broadcast frames #1591
+52
−5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To support DHCP for IPoIB links, DHCP clients and servers require the ability to transmit link-layer broadcasts on the IB interfaces. BPF provides the mechanism for doing this. This change updates the if_infiniband driver to be capable of accepting link-layer broadcast requests via BPF using Ethernet formatted frames (the driver currently registers with BPF as DLT_EN10MB). Only Broadcast frames can reliably be interpreted using the Ethernet header format so detect unicast and multicast frames are rejected if passed in using the Ethernet format. This doesn't impact the ability to support native unicast, broadcast or multicast frames if native infiniband header support is added to BPF at a later date. Further the above, this commit also addresses an issue in the existing code that can result in separation of part of the packet header from the rest of the payload if a BPF write was attempted. This was caused by mbuf preallocation of the infiniband header length regardless of length of the prepend data.
ndance-vdura
changed the title
|
@glebius and @chmeeedalf: When I looked around the IB / IP-over-IB code, it looks like you two have made the only non-trivial changes since we lost Hans Petter. This change looks okay to us within VDura (formerly known as Panasas), but I was hoping to get some expert eyes on it, rather than just committing it on my own. Can either of you take a look? |
|
I'm not expert. All my changes to infiniband are related to large network stack sweeping cleanups. I never touched infiniband hardware. If you use it in VDura, you probably should consider becoming maintainers :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change is predominantly focused at being able to support DHCP for IPoIB network interfaces utilizing the if_infiniband.c driver.
To do this, DHCP clients and servers require the ability to transmit link-layer broadcasts on the IB interfaces using BPF. In the current driver implementation, this isn't possible as frames transmitted via BPF become mangled (whether using IB or Ethernet headers).
This change updates the if_infiniband driver to be capable of accepting link-layer broadcast requests via BPF using Ethernet formatted frames as this honors the DLT_EN10MB type the driver uses to bind to BPF. Only Broadcast frames can reliably be interpreted using the Ethernet header format so unicast and multicast frames are rejected if passed in using the Ethernet header format. This is, however, sufficient to support the primary DHCP use case this commit aims to address. The ability to support unicast, broadcast or multicast frames should not be impacted if native infiniband header support is added to BPF at a later date.