Michael, On Oct 19, 2007, at 4:50 PM, Michael Speer wrote:
> Nicolas, > > On Oct 19, 2007, at 3:33 PM, Nicolas Droux wrote: > >> <snip> >> >>> - How multiple mac address assigned to a single client correspond >>> to the rings owned by the client >> >> I don't agree that this is required for the port as part of the >> initial Crossbow putback. From what I could tell LDOMs today doesn't >> allow multiple MAC addresses to be assigned to vnets in the first >> place. > > The issue is not multiple MAC addresses for a vnet. It's that the > vSwitch > fronts mutliple MAC addresses for many vnet clients. Hence, if a > vswitch > is a single MAC client, then it needs to be assign multiple MAC > addresses > to distribute packets for multiple L2 destinations. This is the > existing > functionality in vSwitch. There are two things being discussed here. One is associating more than one MAC unicast addresses with a MAC client. The interface being reviewed allows this. The other is within a MAC client to assign individual hardware rings to the unicast addresses of the same MAC client. That we cannot support. In order to do this you need to create multiple MAC clients with their own set of rings. The MAC layer is designed to do the multiplexing and virtualization among multiple MAC clients, not within a MAC client. Having the vswitch as one MAC client and implement some of the same functionality as the MAC layer would be inefficient, and wouldn't allow it to take advantage of the features now provided by the MAC layer. In order to take advantage of Crossbow, the vswitch should associate one or more MAC clients in the service domain with each vnet. >>> - Usage of HW mac addr slots in the NIC and automatic switching >>> to layer-2 filtering and promisc mode. >> >> I think I answered your questions about this point below. Also today >> there's no hardware classification done in hardware for LDOMs, >> whether in promiscuous mode or not. So I don't understand why you >> consider this a requirement for the initial port. > > The may be a terminology issue here. So,the existing vSwitch uses > L2 Hardware > classification in nxge, bge, and e1000g for example to filter > incoming packets. That's not what we call hardware classification in Crossbow terminology. What we refer to as hardware classification is directing traffic to one or more rings based on the content of the packet headers. > Each domain's L2 address is placed in hardware address slot. If > the slots are > exhausted, the switch will then decide whether to put the interface > into promiscuous > mode or not. This is what the new MAC layer does as well. Did Narayan mean "switching *between* L2 filtering and promisc mode" instead of "switching *to* L2 filtering and promisc mode" then? Nicolas. -- Nicolas Droux - Solaris Core OS - Sun Microsystems, Inc. droux at sun.com - http://blogs.sun.com/droux
