Code refs

• include/uapi/linux/veth.h
• enum defining veth types in above file
• include/uapi/linux/vfio.h
• looks like it defines ioctl and virtual file i/o wrappers. Now, the interesting thing is that it also, provides some IOMMU types and functions.

Important findings

I see a couple of structs that’s making me super interested in my approach for Kaos.

But, I actually need to understand how this plays with the stack to understand how to use this.

But, I see the following structs, in the net drivers file veth.c:

1. veth_stats -> This holds data, that I can providing monitoring with. Also, the first hint of xdp support is visible here

2. veth_rq_stats -> This will give me runqueue stats. This would be critical in figuring out how much it interferes in profiling heavy applications

3. I see the xdp struct has a ref to sk_buff , and I see a conversion function. Does this mean, that everything veth does is by default xdp? If so,why?

4. net_device_ops This seems to define what the spoofed net device in userspace would be like. Maybe, I can use this to follow my previous thought, of providing certain configurations for popular hardware? e.g: intel T2, T4, mellanox etc. But, that would require thinking if I can even provide the actual dma structure that they support. Actually, what about vfio for this use case? This is a complete tangent and I don’t want to bog this down for first release, interesting thought though.

5. veth_setup() This sets up the net device, and certain features from what I can see. The features include: NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HW_CSUM | \ NETIF_F_RXCSUM | NETIF_F_SCTP_CRC | NETIF_F_HIGHDMA | \ NETIF_F_GSO_SOFTWARE | NETIF_F_GSO_ENCAP_ALL | \ NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX | \ NETIF_F_HW_VLAN_STAG_TX | NETIF_F_HW_VLAN_STAG_RX

   This is amazing! And gives me exactly an idea on what I can do.

So, the main thing is, it looks like veth is defined as a form of net driver for a veth netdev. So, it should technically follow the same path as a normal packet, through sk_buff and so on. But, the curious thing here is actually, the default data path being xdp. I wonder why that is, and if that is indeed what it is doing. Also, how much of this interface is really exposed to a userspace lib?

Also, the veth_setup method, sets a lot of private flags for the netdevice, which changes what the dev can actually do. For example, it sets IFF_DISABLE_NETPOLL which disables netpoll at run-time. This would change how realistic I can make this harness