netdev - Re: Which tool to use?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 29 Jan 2010 10:51:13 +1030
From:	Mark Smith <lk-netdev@...netdev.nosense.org>
To:	"Williams, Mitch A" <mitch.a.williams@...el.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	Stephen Hemminger <shemminger@...tta.com>
Subject: Re: Which tool to use?

On Wed, 27 Jan 2010 23:10:04 -0700
"Williams, Mitch A" <mitch.a.williams@...el.com> wrote:

> Which tool to use?
> 
> Just looking for a bit of direction before I go off and start coding...
> 
> Our SR-IOV capable parts (like everybody else's) include simple built-in
> Layer 2 switch, to allow packets to be switched between the various VF 
> devices.
> 
> We need the capability of configuring this switch from userspace. There
> are a few features we'd like to control, like anti-spoofing, and
> storm control, as well as being able to completely disable the internal
> switch for external loopback.  Mostly, however, we want to be able to add
> new MAC address filters to the switch.
> 
> This is actually a pressing need, for SR-IOV to be really usable in
> a virtualized environment. In most use cases, along with VMs that are
> assigned VF devices, there will be a bunch of VMs talking through the PF
> device via a bridge.  We need to add the MAC addresses of these VMs to
> the on-board switch, or other VMs using the VF devices won't be able to
> talk to them - the packets will go out on the wire instead.
> 
> So, which tool do I modify to make this happen? Ethtool, or ip?  I can
> think of convincing arguments for either, so I want to double-check with
> the maintainers before I dive in.
> 

As they're bridging functions, I think being able to use the
existing brctl bridging utility / interface / api would be both useful
and intuitive. 

> Thanks,
> Mitch
> 
> -------
> If we knew what it was we were doing, it would not be called research,
> would it?
>                                    - Albert Einstein
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html