Index | Thread | Search

From:
Jan Klemkow <jan@openbsd.org>
Subject:
Re: let tun/tap receive large frames
To:
David Gwynne <david@gwynne.id.au>, tech@openbsd.org
Date:
Tue, 28 Jan 2025 19:35:03 +0100

Download raw body.

Thread
On Sun, Nov 17, 2024 at 02:20:57PM GMT, Claudio Jeker wrote:
> On Thu, Nov 14, 2024 at 02:13:44PM +1000, David Gwynne wrote:
> > ie, let writes from userland go big.
> > 
> > there's no reason we shouldn't be able to take a large packet from
> > userland. however, because there's "link" headers on packets, we may
> > need to chain mbufs now.
> > 
> > it also reorganises the mbuf setup so tun_hdr (if present) isn't
> > included in the size.
> > 
> > ok?
> 
> Not sure about this limit here: uio->uio_resid > (hlen + MAXMCLBYTES)
> It feels like MAXMCLBYTES is not really the right define but I see nothing
> better.
> 
> OK claudio@

We should also adjust these constants.  So, the userland knows about
the new sizes.

ok?

bye,
Jan

Index: net/if_tun.h
===================================================================
RCS file: /cvs/src/sys/net/if_tun.h,v
diff -u -p -r1.18 if_tun.h
--- net/if_tun.h	17 Nov 2024 00:25:07 -0000	1.18
+++ net/if_tun.h	17 Jan 2025 09:35:15 -0000
@@ -89,10 +89,10 @@ struct tun_hdr {
 #define	TUN_READY	(TUN_OPEN | TUN_INITED)
 
 /* Maximum packet size */
-#define	TUNMTU		3000
+#define TUNMTU		MAXMCLBYTES
 
 /* Maximum receive packet size (hard limit) */
-#define TUNMRU          16384
+#define TUNMRU		MAXMCLBYTES
 
 /* iface info */
 struct tuninfo {