Message-ID: <CALHoRjctagiFOWi8OWai5--m+sezaMHSOpKNLSQbrKEgRbs-KQ@mail.gmail.com>
Date:   Mon, 21 Nov 2022 18:59:11 -0800
From:   Steve Williams <steve.williams@...cruise.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org
Subject: Re: [EXT] Re: [PATCH net-next] sandlan: Add the sandlan virtual
 network interface

I have had trouble with the veth driver not transparently passing the
full ethernet packets unaltered, and this is wreaking havoc with the
hanic driver that I have (and that I'm submitting separately). That,
and veth nodes only come in pairs, whereas with sandlan I can make
more complex LANs and that allows me to emulate more complex
situations. But fair point, and I am looking more closely at figuring
out exactly what the veth driver is doing to my packets.

On Thu, Nov 17, 2022 at 8:00 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Wed, 16 Nov 2022 14:24:29 -0800 Steve Williams wrote:
> > This is a virtual driver that is useful for testing network protocols
> > or other complex networking without real ethernet hardware. Arbitrarily
> > complex networks can be created and simulated by creating virtual network
> > devices and assigning them to named broadcast domains, and all the usual
> > ethernet-aware tools can operate on that network.
> >
> > This is different from e.g. the tun/tap device driver in that it is not
> > point-to-point. Virtual lans can be created that support broadcast,
> > multicast, and unicast traffic. The sandlan nics are not tied to a
> > process, but are instead persistent, have a mac address, can be queried
> > by iproute2 tools, etc., as if they are physical ethernet devices. This
> > provides a platform where, combined with netns support, distributed
> > systems can be emulated. These nics can also be opened in raw mode, or
> > even bound to other drivers that expect ethernet devices (vlans, etc),
> > as a way to test and develop ethernet based network protocols.
> >
> > A sandlan lan is not a tunnel. Packets are dispatched from a source
> > nic to destination nics as would be done on a physical lan. If you
> > want to create a nic to tunnel into an emulation, or to wrap packets
> > up and forward them elsewhere, then you don't want sandlan, you want
> > to use tun/tap or other tunneling support.
>
> As a general rule we don't accept any test/emulation code upstream
> unless it comes with some tests that actually use it.
> We have had bad experience with people adding virtual interfaces and
> features which then bit rot or become static checker fodder and we
> don't know whether anyone is actually using them and how.
>
> Is there something here that you can't achieve with appropriately
> combined veths?

I use the sandlan virtual interfaces to test my hanic driver, which I also just
posted as a patch. The hanic driver implements redundant links and sets
ethernet mac addresses, and also uses those mac addresses to infer streams
for deduplication. The veth driver only creates pairs of nics, and it doesn't
seem to support setting  the mac address



--

Stephen Williams

Senior Software Engineer

Cruise

-- 


*Confidentiality Note:* We care about protecting our proprietary 
information, confidential material, and trade secrets. This message may 
contain some or all of those things. Cruise will suffer material harm if 
anyone other than the intended recipient disseminates or takes any action 
based on this message. If you have received this message (including any 
attachments) in error, please delete it immediately and notify the sender 
promptly.

Powered by blists - more mailing lists