IP stack: Ideas for optimizations

[zephyrbot]

Reported by Paul Sokolovsky:

These are background ideas how to squeeze more free code bytes/cpu cycles from IP stack. nothing here is priority for now, while we still work on making it functionally complete and hunt bugs.

• In pretty many places we use uint16_t, for RISCs this likely leads to more instructions generated than uint32_t.
• In net_ipv4_finalize_raw()/net_ipv6_finalize_raw() we call net_pkt_compact(), which is kinda away from "zero-copy" behavior. Consider if things like 6lowpan over BLE/802.15.4 can send non-full frames as parts of IPv6 packet. Similarly for other L2's.

(Imported from Jira ZEP-2106)

[zephyrbot]

by Tomasz Bursztyka:

There is not really any 0-copy followed behavior in the stack. Actually, it's note really possible to get that.
I don't get the relation you make with net_pkt_compact and 6lo. Actually 6lo, during compression, is going to run net_pkt_compact(). Now, maybe it's not relevant to put it on these *_finalize_raw() functions.

About the u16_t, do you have any example? At least, in structs, it's meant to save RAM (getting along another u16_t, or 2 u8_t, etc...) and I would say that saving RAM on such OS is of greater importance than performance.

[zephyrbot]

by Jukka Rissanen:

Initially we had an ambitious goal to try to have a zero-copy data path from "user space" to network driver. For some network bearers this is possible (like ethernet) but for some with 6lo like 802.15.4 and BT it is not.
About the net_pkt_compact(), its purpose is to check if the packets needs to be compacted. It will do nothing if all the data is properly set.

[zephyrbot]

by Jukka Rissanen:

Some more clarifications for the use of net_pkt_compact(). At the moment it is called unconditionally in ipv6.c and this can be done like this. But for ethernet we could do it so that it is not called, in which case we would have a zero copy for ethernet. The reason for this is that as the ethernet MTU is so much larger than the typical packet size (128), we do not need to actually compact the sent packet here. This is not the case for 6lo based technologies like 802.15.4 where we must have all the network packets partitioned properly before the compression is done.

[zephyrbot]

by Paul Sokolovsky:

Tomasz, Jukka: Thanks for comments. This ticket was intended to be a low-priority dump to record some rough ideas of possible optimizations so they weren't forgotten - as at the current stage, any optimization would be indeed premature. So, I appreciate the comments, and by all means, please share your ideas or concerns here. I'll reply when work on more priority things permits (as the above are just speculations, replies on them would require more research/experimentation).

[zephyrbot]

by Paul Sokolovsky:

As a follow-up to #1181 . For Zephyr in particular, and also Linux, and arguably any other reasonably implemented system, the layout of {{struct sockaddr_in}} vs {{struct sockaddr_in6}} such that offset and size of "port" field is the same, and offset of "addr" field is also the same:

{code:java}
struct sockaddr_in6 {
sa_family_t sin6_family; /* AF_INET6 /
u16_t sin6_port; / Port number /
struct in6_addr sin6_addr; / IPv6 address /
u8_t sin6_scope_id; / interfaces for a scope */
};

struct sockaddr_in {
sa_family_t sin_family; /* AF_INET /
u16_t sin_port; / Port number /
struct in_addr sin_addr; / IPv4 address */
};
{code}

Spelling out this fact explicitly (similarly to how POSIX explicitly requires "family" field of all of struct sockaddr, struct sockaddr_storage, struct sockaddr_in, struct sockaddr_in6 to be aligned), would allow to write more clear, concise, and likely efficient code, as the compiler probably doesn't optimize current typical code:

{code}
struct sockaddr *sockaddr;
int port;

if (sockaddr->sa_family == AF_INET) {
struct sockaddr_in *sockaddr4 = (struct sockaddr_in *)sockaddr;
port = sockaddr4->sin_port;
} else if (sockaddr->sa_family == AF_INET6) {
struct sockaddr_in6 *sockaddr6 = (struct sockaddr_in6 *)sockaddr;
port = sockaddr6->sin_port;
}
{code}

[pfalcon]

While we aren't yet in the optimization stage, some more obvious issues are already being addressed: #4421

[pfalcon]

I find it harder and harder to look thru code and not do anything about it. #4673.

[tbursztyka]

I find it harder and harder to look thru code and not do anything about it.

All out of bubblegum? ;P