diff options
author | David Gwynne <dlg@cvs.openbsd.org> | 2024-11-17 00:25:08 +0000 |
---|---|---|
committer | David Gwynne <dlg@cvs.openbsd.org> | 2024-11-17 00:25:08 +0000 |
commit | ce8a47fdbfec7dfa9d85b883396e1085bfc86fd5 (patch) | |
tree | 1aeba7c580c63658d4c1b5b517431bc7b90ba248 /distrib | |
parent | 6ddc2616716ff77eec54b3a9c5cbe497bc6ee4a6 (diff) |
provide network offloads between the kernel and userland again
userland can request that network packets that are read from or
written to the device special file get prepended with a "tun_hdr"
struct. this struct contains bits which say what offloads are
requested for the packet, including things like ip/tcp/udp/icmp
checksums, tcp segmentation offloads, or ethernet vlan tags.
userland can write a packet with any of these offloads requested
into the kernel at any time, but has to request which ones it's
able to handle coming from the kernel. enabling the tun_hdr struct
and which offloads userland can handle is done with a new TUNSCAP
ioctl.
this is based on the virtio_net_hdr in linux, which jan@ actually
implemented and had working with vmd. however, claudio@ and i
strongly opposed to what feels like a layer violation by pulling
virtio structures into the tun driver, and then trying to emulate
virtio/linux semantics in our network stack, and playing catch up
when the "upstream" projects decide to change the shape or meaning
of these bits. tun_hdr is specific to the openbsd network stack and
it's semantics, which simplifies our kernel implementation. jan has
been pretty gracious about the extra work on the vmd side of things.
tested by and ok jan@
ok claudio@
sthen@ backed this out cos of confusion with the ioctl numbers i
picked to controlling this feature. i've picked new numbers that
don't conflict this time.
Diffstat (limited to 'distrib')
0 files changed, 0 insertions, 0 deletions