Conversation
Signed-off-by: Till Wegmueller <toasterson@gmail.com>
|
Rename feth to unet ("userland net"), following illumos naming convention (simnet, uscsi) rather than the macOS feth name. Also because it reminds more of FUSE. Adopt SmartOS frameio as the primary data path. One-syscall-per-packet is a known bottleneck; the IPD now proposes porting the frameio framework from SmartOS (sys/frameio.h, frameio.c) and building batched ioctls (UNET_IOC_FRAMEIO_READ/WRITE, up to 32 frames per call with scatter-gather) as the primary interface. read(2)/write(2) remain as a convenience fallback for portability and simple consumers. Add vnd(4D) and viona as prior art. vnd demonstrates the batched frame I/O model and data queue architecture we adopt; viona demonstrates MAC-direct architecture and is noted for context though its VMM coupling makes it unsuitable as a direct model. Describe the sdev plugin for /dev/unet/. The zone support section now explains the sdev_plugin_ops interface (spo_validate, spo_filldir, spo_inactive), how the driver registers with sdev during attach, and the per-zone /dev/unet/ and global zone /dev/unet/zone// namespace. Making a large explanation here as it is modeled after vnd(4D) which is not upstream. Clarify /dev/net/ is observability-only per Bill's feedback. The character device section now states /dev/net/ nodes are for packet capture and should not be written to; /dev/unet/ is the exclusive frame I/O interface using plain cb_ops, not DLPI. So new people get some context when simply reading the IPD and haven't yet dove into the source code. Add explicit data queue model with dual read/write queues, configurable buffer sizes via ioctl, write-side no-drop guarantee, and POLLIN/POLLOUT support for event-driven I/O. Add I/O mode observability (link property and kstat reporting whether consumer uses frameio or read/write). Add per-device kstat section covering MAC stats and unet-specific counters. |
|
I didn't see this mentioned yet, so for some more possibly relevant context, see the "tuntap" driver used with OpenVPN and others. |
|
Thats's old driver which I had issues with and which I am trying to get a more performant/modern replacement. |
The main Use case for this work is a VPN for lower end setups, Homelabs etc. which does not frequently crash or lock up when some traffic other than some minor SSH happens.