netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Steve Williams <steve.williams@getcruise.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net-next] sandlan: Add the sandlan virtual network interface
Date: Thu, 17 Nov 2022 20:00:46 -0800	[thread overview]
Message-ID: <20221117200046.0533b138@kernel.org> (raw)
In-Reply-To: <20221116222429.7466-1-steve.williams@getcruise.com>

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?

  parent reply	other threads:[~2022-11-18  4:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16 22:24 [PATCH net-next] sandlan: Add the sandlan virtual network interface Steve Williams
2022-11-17  0:33 ` Andrew Lunn
2022-11-17  5:35 ` kernel test robot
2022-11-18  4:00 ` Jakub Kicinski [this message]
2022-11-22  2:59   ` [EXT] " Steve Williams
2022-11-22  4:02     ` Jakub Kicinski
2022-11-22 20:09     ` Andrew Lunn
2022-11-29 17:54       ` Steve Williams
2023-02-21 10:19         ` Ferenc Fejes
2022-11-21 14:04 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221117200046.0533b138@kernel.org \
    --to=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=steve.williams@getcruise.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).