perf: Don't call read_unaligned in getter_be#84
Conversation
All the variants carried by them have the same size (4 bytes). Given than using C-style unions in Rust makes it difficult to use serialization libraries, remove them and instead define the `data` fields as `[u8; 4]`, then implement our own (safe) abstraction that allow users to check and access the appropriate variants (depending on the ICMP type). Keep the unsafe variants public as well.
It unnecessarily adds a redundant copy, especially on little-endian targets, where call to `swap_bytes` (that calls the `bswap` intrinsic) already makes an another copy.
10b41a3 to
ac41cfc
Compare
|
@aureliar8 this is somehow similar to the PR you have opened and closed about the alignment of 4 |
|
Yeah it's similar to what I tried to do in #73 But nowadays I don't think Yes the kernel will make sure that when creating a packet buffer, the first IP header is 4-aligned. In theory all sane encapsulation protocol make that the inner packets are all 2-aligned, so we could simply update this PR to use But the more I think about it the more I consider that for the ebpf usecase, the alignment can not be a property of the type itself: it's a property of the instance of this type. I think the most flexible approach would be that it's up to the caller to decide if he wants to do an aligned-read or an unaligned read. Because he's the only one to know where in the packet he is looking. This means increasing the API surface of those type quite significantly and we'd need to duplicate each |
3 participants
It unnecessarily adds a redundant copy, especially on little-endian targets, where call to
swap_bytes(that calls thebswapintrinsic) already makes an another copy.This change is