diff options
| author | David Gibson <david@gibson.dropbear.id.au> | 2025-03-12 13:18:36 +1100 |
|---|---|---|
| committer | Stefano Brivio <sbrivio@redhat.com> | 2025-03-12 23:08:33 +0100 |
| commit | c4bfa3339cea586172d4b0fcd613b5638498651e (patch) | |
| tree | c8bdbdf911550d4b1a6e96135245d7f37a782596 /contrib/qemu | |
| parent | 1eda8de4384a93778a781257781c5b0967c8abfe (diff) | |
| download | passt-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
