From: Or Gerlitz <ogerlitz@voltaire•com>
To: Alexander Duyck <alexander.h.duyck@intel•com>
Cc: Alexander Duyck <alexander.duyck@gmail•com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel•com>,
"Fischer, Anna" <anna.fischer@hp•com>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
David Miller <davem@davemloft•net>,
Stephen Hemminger <shemminger@linux-foundation•org>
Subject: Re: L2 switching in igb
Date: Mon, 14 Sep 2009 13:02:52 +0300 [thread overview]
Message-ID: <4AAE14CC.2000609@voltaire.com> (raw)
In-Reply-To: <4AA937A1.9070504@intel.com>
Alexander Duyck wrote:
> You are correct, the vSwitch can basically do VEPA by disabling local
> loopback enable bit in the DTXSWC register. This would force all
> traffic from the PF/VFs out the lan physical port and from the lan
> physical port to the appropriate PF/VFs without doing any switching in
> between PF/VFs.
To have VEPA support another bit has to be programmed... its the one
that doesn't let the PF to forward a packet to a VF whose source mac
matches the one in the packet (e.g multicast sender).
> add an rtnl_link_ops interface to handle vSwitch configuration that
> could then be applied to the igb netdevs that support VEPA/vSwitch
> technologies. A subset of that interface could then be dedicated to
> VF configuration to handle things such as spawning VFs, setting the
> default mac addresses, security controls, etc.
Yes, lets do that. I'd like to suggest that a "VF programmable from user
space" context will contain a <mac, vlan-id, priority-bits, rate>
tuple, such that in the absence of vlan tag, the VF driver will "sign"
the packet (skb) with vlan-id and priority-bits assigned by the admin
and the PF NIC will mandate that the VF originated traffic will not
exceed the rate.
Or.
Or.
next prev parent reply other threads:[~2009-09-14 10:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-03 9:16 L2 switching in igb Or Gerlitz
2009-09-04 4:35 ` Alexander Duyck
2009-09-10 8:04 ` Or Gerlitz
2009-09-10 17:30 ` Alexander Duyck
2009-09-14 10:02 ` Or Gerlitz [this message]
2009-09-15 2:52 ` Alexander Duyck
2009-09-15 13:19 ` Or Gerlitz
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=4AAE14CC.2000609@voltaire.com \
--to=ogerlitz@voltaire$(echo .)com \
--cc=alexander.duyck@gmail$(echo .)com \
--cc=alexander.h.duyck@intel$(echo .)com \
--cc=anna.fischer@hp$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=jeffrey.t.kirsher@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shemminger@linux-foundation$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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