Re: rump_server(1) and vether(4)

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

On Sat, 21 Sep 2024 08:51:01 -0400
Greg Troxel <gdt%lexort.com@localhost> wrote:

> Sad Clouds <cryintothebluesky%gmail.com@localhost> writes:
> 
> > Hi, current documentation at:
> > https://www.netbsd.org/docs/rump/sptut.html
> >
> > suggests using tap(4) and bridge(4) on the host, then within rump
> > server virt(4) can be used to provide connectivity via tap(4).
> >
> > However, NetBSD-10 tap(4) man page states:
> >
> > CAVEATS
> > Starting from NetBSD 10.0, the tap driver can no longer be used as a
> > bridge(4) endpoint because it supports a link state based on if it has
> > been opened or not.  Use the vether(4) driver instead as it's been
> > explicitly designed for this purpose.
> >
> > So the question is - what is the alternative for rump server virt(4) as
> > it seems to only want to open tap(4) devices and not vether(4)?
> 
> My guess is that in 10, vether is split off from tap, and that rump/virt
> was simply not updated to use it instead.  If so, it simply remains for
> someone to fix the code and docs.

This is on NetBSD-10 and I tried tap(2) with bridge(4) and initially it
seemed to work. After a few network tests sending data between
rump_server and the host, it simply grinds to a halt and no more packets
get through. Not sure if this is related to tap(2) or issues with rump
implementation. TCP throughput performance is quite poor, but I guess
this may be expected with rump.