[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AAE14CC.2000609@voltaire.com>
Date: Mon, 14 Sep 2009 13:02:52 +0300
From: Or Gerlitz <ogerlitz@...taire.com>
To: Alexander Duyck <alexander.h.duyck@...el.com>
CC: Alexander Duyck <alexander.duyck@...il.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"Fischer, Anna" <anna.fischer@...com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Stephen Hemminger <shemminger@...ux-foundation.org>
Subject: Re: L2 switching in igb
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.
--
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
Powered by blists - more mailing lists