Changeset View
Changeset View
Standalone View
Standalone View
sys/sys/mbuf.h
Show First 20 Lines • Show All 181 Lines • ▼ Show 20 Lines | struct { | ||||
uint8_t l5hlen; /* layer 5 hdr len */ | uint8_t l5hlen; /* layer 5 hdr len */ | ||||
uint8_t inner_l2hlen; | uint8_t inner_l2hlen; | ||||
uint8_t inner_l3hlen; | uint8_t inner_l3hlen; | ||||
uint8_t inner_l4hlen; | uint8_t inner_l4hlen; | ||||
uint8_t inner_l5hlen; | uint8_t inner_l5hlen; | ||||
}; | }; | ||||
}; | }; | ||||
union { | union { | ||||
union { | |||||
uint8_t eight[8]; | uint8_t eight[8]; | ||||
uint16_t sixteen[4]; | uint16_t sixteen[4]; | ||||
uint32_t thirtytwo[2]; | uint32_t thirtytwo[2]; | ||||
uint64_t sixtyfour[1]; | uint64_t sixtyfour[1]; | ||||
uintptr_t unintptr[1]; | uintptr_t unintptr[1]; | ||||
void *ptr; | void *ptr; | ||||
} PH_per; | } PH_per; | ||||
struct { | |||||
/* Ethernet */ | |||||
uint16_t ether_vtag; /* in and out */ | |||||
uint32_t csum_data; /* inbound */ | |||||
}; | |||||
uint16_t vt_nrecs; /* IGMP and MLD6 */ | |||||
uint16_t lro_nsegs; /* TCP: inbound after LRO */ | |||||
rscheff: This seems to be misaligned compared where it used to be based on the previous #defines... | |||||
glebiusAuthorUnsubmitted Done Inline ActionsRichard, just pushed newer version before reading your comment. Now can't understand to what lines you refer. Sorry. Can you please explain with updated patch? glebius: Richard, just pushed newer version before reading your comment. Now can't understand to what… | |||||
rscheffUnsubmitted Done Inline ActionsYour new revision fixed my concern. Previously, "lro_nsegs" mapped to sixteen[0] instead of sixteen[1], which the new struct {tso_segsz ; lro_nsegs} addresses. Thx. rscheff: Your new revision fixed my concern. Previously, "lro_nsegs" mapped to sixteen[0] instead of… | |||||
struct { | |||||
/* TCP: outbound */ | |||||
uint16_t tcp_tun_port; | |||||
uint16_t tso_segsz; | |||||
}; | |||||
}; | |||||
/* Layer specific non-persistent local storage for reassembly, etc. */ | /* Layer specific non-persistent local storage for reassembly, etc. */ | ||||
union { | union { | ||||
union { | |||||
uint8_t eight[8]; | uint8_t eight[8]; | ||||
uint16_t sixteen[4]; | uint16_t sixteen[4]; | ||||
uint32_t thirtytwo[2]; | uint32_t thirtytwo[2]; | ||||
uint64_t sixtyfour[1]; | uint64_t sixtyfour[1]; | ||||
uintptr_t unintptr[1]; | uintptr_t unintptr[1]; | ||||
void *ptr; | void *ptr; | ||||
} PH_loc; | } PH_loc; | ||||
struct { | |||||
/* TCP: inbound during LRO (no reassembly) */ | |||||
uint16_t lro_tcp_d_len; | |||||
uint16_t lro_tcp_d_csum; | |||||
uint16_t lro_tcp_h_off; | |||||
uint16_t lro_etype; | |||||
}; | }; | ||||
#define ether_vtag PH_per.sixteen[0] | }; | ||||
#define tcp_tun_port PH_per.sixteen[0] /* outbound */ | }; | ||||
#define vt_nrecs PH_per.sixteen[0] /* mld and v6-ND */ | |||||
#define tso_segsz PH_per.sixteen[1] /* inbound after LRO */ | |||||
#define lro_nsegs tso_segsz /* inbound after LRO */ | |||||
#define csum_data PH_per.thirtytwo[1] /* inbound from hardware up */ | |||||
#define lro_tcp_d_len PH_loc.sixteen[0] /* inbound during LRO (no reassembly) */ | |||||
#define lro_tcp_d_csum PH_loc.sixteen[1] /* inbound during LRO (no reassembly) */ | |||||
#define lro_tcp_h_off PH_loc.sixteen[2] /* inbound during LRO (no reassembly) */ | |||||
#define lro_etype PH_loc.sixteen[3] /* inbound during LRO (no reassembly) */ | |||||
/* Note PH_loc is used during IP reassembly (all 8 bytes as a ptr) */ | |||||
/* | /* | ||||
* TLS records for TLS 1.0-1.2 can have the following header lengths: | * TLS records for TLS 1.0-1.2 can have the following header lengths: | ||||
* - 5 (AES-CBC with implicit IV) | * - 5 (AES-CBC with implicit IV) | ||||
* - 21 (AES-CBC with explicit IV) | * - 21 (AES-CBC with explicit IV) | ||||
* - 13 (AES-GCM with 8 byte explicit IV) | * - 13 (AES-GCM with 8 byte explicit IV) | ||||
*/ | */ | ||||
#define MBUF_PEXT_HDR_LEN 23 | #define MBUF_PEXT_HDR_LEN 23 | ||||
▲ Show 20 Lines • Show All 1,469 Lines • Show Last 20 Lines |
This seems to be misaligned compared where it used to be based on the previous #defines...
Should these two lines not also be part of a struct {}, or are these uses all mutually exclusive and the new assignment is ok?