From: Mark Smith <lk-netdev@lk-netdev.nosense.org>
To: "Williams, Mitch A" <mitch.a.williams@intel.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
Stephen Hemminger <shemminger@vyatta.com>
Subject: Re: Which tool to use?
Date: Fri, 29 Jan 2010 10:51:13 +1030 [thread overview]
Message-ID: <20100129105113.239bbaeb@opy.nosense.org> (raw)
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FDD386A6A@rrsmsx501.amr.corp.intel.com>
On Wed, 27 Jan 2010 23:10:04 -0700
"Williams, Mitch A" <mitch.a.williams@intel.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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2010-01-29 0:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-28 6:10 Which tool to use? Williams, Mitch A
2010-01-28 17:59 ` Rose, Gregory V
2010-01-29 0:21 ` Mark Smith [this message]
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=20100129105113.239bbaeb@opy.nosense.org \
--to=lk-netdev@lk-netdev.nosense.org \
--cc=davem@davemloft.net \
--cc=mitch.a.williams@intel.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.