Vxlan tunnel 7717 v2.1 #14018
Vxlan tunnel 7717 v2.1 #14018
Conversation
Instead of directly accessing the field Will allow PacketTunnelType to hold the precise tunnel type like DECODE_TUNNEL_ERSPANII with a modification of PacketIsTunnelChild
So that we know for a packet which precise type of tunnel it is (like erspan2).
ebpf program does not handle 3 layers of vlan
Ticket: 7717 Allows for instance to process/log ARP packets over VXLAN. That means we need to decode the ethernet layer above vxlan instead of skipping it as part of the vxlan, even if the vxlan decoder still checks the ethernet layer to avoid FPs.
to save memory
catenacyber
force-pushed
the
vxlan-tunnel-7717-v2.1
branch
from
08a9479 to
c0f8420
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #14018 +/- ##
==========================================
- Coverage 83.87% 83.84% -0.03%
==========================================
Files 1011 1011
Lines 275671 275675 +4
==========================================
- Hits 231207 231132 -75
- Misses 44464 44543 +79
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
|
Information: QA ran without warnings. Pipeline = 27969 |
|
|
||
| struct PacketL2 { | ||
| enum PacketL2Types type; | ||
| uint8_t type; // enum PacketL2Types |
There was a problem hiding this comment.
I don't think this will safe anything due to alignment requirements of the pointer that follows
|
|
||
| struct PacketL3 { | ||
| enum PacketL3Types type; | ||
| uint8_t type; // enum PacketL3Types |
There was a problem hiding this comment.
alignment of pointers in hdrs will lead to this not saving any space I think
There was a problem hiding this comment.
On 32-bit architecture, it would, right ?
There was a problem hiding this comment.
we don't optimize for 32 bit anymore, in fact we're considering dropping official support for it
| }; | ||
|
|
||
| struct PacketL4 { | ||
| enum PacketL4Types type; |
There was a problem hiding this comment.
again I expect no practical effect here due to alignment
|
Next in #14020 |
3 participants
Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/7717
Describe changes:
SV_BRANCH=OISF/suricata-verify#2521
Let me know if you want to handle the ebpf maps commit separately
These are the first commits of #13839 with a dedicated ticket
#14014 with cleaner history and SV rebased on latest
Note: there are other structures that may benefit from such an optimization :
git grep "enum " src/*.h | grep ';' | grep -v ');'For example in
struct SSLState_: