aboutgitcodebugslistschat
path: root/contrib/qemu
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2025-03-12 13:18:36 +1100
committerStefano Brivio <sbrivio@redhat.com>2025-03-12 23:08:33 +0100
commitc4bfa3339cea586172d4b0fcd613b5638498651e (patch)
treec8bdbdf911550d4b1a6e96135245d7f37a782596 /contrib/qemu
parent1eda8de4384a93778a781257781c5b0967c8abfe (diff)
downloadpasst-c4bfa3339cea586172d4b0fcd613b5638498651e.tar
passt-c4bfa3339cea586172d4b0fcd613b5638498651e.tar.gz
passt-c4bfa3339cea586172d4b0fcd613b5638498651e.tar.bz2
passt-c4bfa3339cea586172d4b0fcd613b5638498651e.tar.lz
passt-c4bfa3339cea586172d4b0fcd613b5638498651e.tar.xz
passt-c4bfa3339cea586172d4b0fcd613b5638498651e.tar.zst
passt-c4bfa3339cea586172d4b0fcd613b5638498651e.zip
tap: Use explicit defines for maximum length of L2 frame
Currently in tap.c we (mostly) use ETH_MAX_MTU as the maximum length of an L2 frame. This define comes from the kernel, but it's badly named and used confusingly. First, it doesn't really have anything to do with Ethernet, which has no structural limit on frame lengths. It comes more from either a) IP which imposes a 64k datagram limit or b) from internal buffers used in various places in the kernel (and in passt). Worse, MTU generally means the maximum size of the IP (L3) datagram which may be transferred, _not_ counting the L2 headers. In the kernel ETH_MAX_MTU is sometimes used that way, but sometimes seems to be used as a maximum frame length, _including_ L2 headers. In tap.c we're mostly using it in the second way. Finally, each of our tap backends could have different limits on the frame size imposed by the mechanisms they're using. Start clearing up this confusion by replacing it in tap.c with new L2_MAX_LEN_* defines which specifically refer to the maximum L2 frame length for each backend. Signed-off-by: David Gibson <dgibson@redhat.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'contrib/qemu')
0 files changed, 0 insertions, 0 deletions