-
Notifications
You must be signed in to change notification settings - Fork 81
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
Add raweth data length header field #294
Changes from 3 commits
4085e00
2df5186
2df748d
ae0196c
1093791
e4f4753
f4d6807
dae9f87
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -36,6 +36,7 @@ typedef struct { | |
uint8_t dmac[_ZP_MAC_ADDR_LENGTH]; // Destination mac address | ||
uint8_t smac[_ZP_MAC_ADDR_LENGTH]; // Source mac address | ||
uint16_t ethtype; // Ethertype of frame | ||
uint16_t data_length; // Payload length | ||
} _zp_eth_header_t; | ||
|
||
typedef struct { | ||
|
@@ -44,6 +45,7 @@ typedef struct { | |
uint16_t vlan_type; // Vlan ethtype | ||
uint16_t tag; // Vlan tag | ||
uint16_t ethtype; // Ethertype of frame | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 802.3 raw requires us to use a 802.2 LLC header which would be 3 bytes of useless information for us, so I figured an ethertype and a frame length was the most efficient choice. |
||
uint16_t data_length; // Payload length | ||
} _zp_eth_vlan_header_t; | ||
|
||
typedef struct { | ||
|
@@ -61,6 +63,8 @@ int8_t _z_open_raweth(_z_sys_net_socket_t *sock, const char *interface); | |
size_t _z_send_raweth(const _z_sys_net_socket_t *sock, const void *buff, size_t buff_len); | ||
size_t _z_receive_raweth(const _z_sys_net_socket_t *sock, void *buff, size_t buff_len, _z_bytes_t *addr); | ||
int8_t _z_close_raweth(_z_sys_net_socket_t *sock); | ||
size_t _z_raweth_ntohs(size_t val); | ||
size_t _z_raweth_htons(size_t val); | ||
|
||
#endif | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -116,7 +116,7 @@ int8_t _z_multicast_send_n_msg(_z_session_t *zn, const _z_network_message_t *n_m | |
} else { | ||
// The message does not fit in the current batch, let's fragment it | ||
// Create an expandable wbuf for fragmentation | ||
_z_wbuf_t fbf = _z_wbuf_make(ztm->_wbuf._capacity - 12, true); | ||
_z_wbuf_t fbf = _z_wbuf_make(ztm->_wbuf._capacity - _Z_FRAGMENT_HEADER_SIZE, true); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The fragmentation buffer should allocate a small amount of memory and it shouldn't be dependent on the fragment header size. |
||
|
||
ret = _z_network_message_encode(&fbf, n_msg); // Encode the message on the expandable wbuf | ||
if (ret == _Z_RES_OK) { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -125,7 +125,7 @@ int8_t _z_unicast_send_n_msg(_z_session_t *zn, const _z_network_message_t *n_msg | |
} else { | ||
// The message does not fit in the current batch, let's fragment it | ||
// Create an expandable wbuf for fragmentation | ||
_z_wbuf_t fbf = _z_wbuf_make(ztu->_wbuf._capacity - 12, true); | ||
_z_wbuf_t fbf = _z_wbuf_make(ztu->_wbuf._capacity - _Z_FRAGMENT_HEADER_SIZE, true); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See my comment on the fragment header size above. |
||
|
||
ret = _z_network_message_encode(&fbf, n_msg); // Encode the message on the expandable wbuf | ||
if (ret == _Z_RES_OK) { | ||
|
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.
This is actually not true, the fragment header size may vary depending on the used protocol extension.
As a consequence, basing the code logic on this value may lead to some bugs.
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.
I'd say we should fix this in another PR, I opened an issue on the overall issue: #295