Re: [RFC NET 00/02]: Secondary unicast address support
Ben Greear wrote: Patrick McHardy wrote: Eric W. Biederman wrote: For the macvlan hash you just use an upper byte. Is that just a simple starting place, or do we not need a more complex hash. That gave me an idea, since the default addresses are random anyway I'm now using an incrementing counter for the upper byte. Is there not a (relatively) easy way to hash the entire 6 bytes? I'd prefer to be able to set the MACs to anything I want, without worrying about trivially hitting a worst-case hash scenario. That would only happen if all your addresses have the same high byte. I can't see a reason why you would want to do this, even with manually configured addresses its still reasonable to expect a uniform distribution. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC NET 00/02]: Secondary unicast address support
Eric W. Biederman wrote: Ben Greear [EMAIL PROTECTED] writes: Patrick McHardy wrote: Eric W. Biederman wrote: For the macvlan code do we need to do anything special if we transmit to a mac we would normally receive? Another unicast mac of the same nic for example. That doesn't happen under normal circumstances. I don't believe it would work. Assuming you mean you want to send between two mac-vlans on the same physical nic... This can work if your mac-vlans are on different subnets and you are routing between them (and if you have my send-to-self patch or have another way to let a system send packets to itself). Ok. I didn't know if you could trigger this case without without having then endpoints in separate namespaces. I was suspecting the routing code would realize what we were doing realize the route is local and route through lo. The routing code will short-circuit by default. It takes quite a bit of effort to make them _not_ short circuit..that is what I was talking about. Mac-vlans will be just like any other ethernet nics as far as routing goes. A normal ethernet switch will NOT turn a packet around on the same interface it was received, so that is why you must have them on different subnets and have a router in between. Yes. That is essentially the configuration I was wondering about. For sending directly to yourself, something like the 'veth' driver is probably more useful. True. And I think it has a place. However the common case with the tunnel devices is to just hook them all up to an ethernet bridge as well as a real ethernet device. The far ends of the ethernet tunnels are dropped into different namespaces. Which gets a very similar effect to the mac vlan code. I'm just wondering if I can not setup an ethernet tunnel device when my primary purpose is to talk to the outside world, but occasionally want a little in the box traffic. mac-vlans should work on veth devices just fine, and the veths will also short-circuit route (at least if they are in the same namespace). I'm not sure I understand what you are trying to do..but in general both veth and mac-vlans should act like ethernet nics..so if you can find some way that does _not_ hold, please let us know. Thanks, Ben Eric - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC NET 00/02]: Secondary unicast address support
Patrick McHardy [EMAIL PROTECTED] writes: These two patches contain a first short at secondary unicast address support. I'm still working on converting macvlan as an example, but since I'm about to leave for tonight I thougth I'd get them out for some comments now. The patch adds two new functions dev_unicast_add and dev_unicast_delete to add/remove addresses. Similar to dev_mc_add/dev_mc_delete they do refcounting of the addresses and the address on a list associated with the device. dev_address_upload is responsible for uploading both the multicast and unicast list to the device. Devices that are capable of filtering multiple unicast addresses need to provide a function dev-set_address_list that deals with setting both unicast and multicast address filters. This seemed like the easiest way for chips containing filters that can be used for any address type, also parts of the logic when to use HW filters is similar for unicast and multicast addresses. Devices not providing this function are put in promiscous mode when secondary addresses are present and the old set_multicast_list function is called to take care of multicast filtering. The dev_uc_list structure is kept similar to dev_mc_list to allow easier integration in existing fill address filters loops. E1000 is converted as an example, the patch worked fine in some limited testing. Comments welcome. I'm trying to understand what the point of this patch is. In once sense I find the concept of filtering and listening for multiple mac addresses very interesting, especially if we could break out different streams of traffic by destination mac address into separate network devices. This would remove the need to any kind of ethernet tunnel and makes multiple network namespaces much more pleasant. However this just seems to allow a card to decode multiple mac addresses which in some oddball load balancing configurations may actually be useful, but it seems fairly limited. Do you have a specific use case you envision for this multiple mac functionality? Eric - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC NET 00/02]: Secondary unicast address support
From: [EMAIL PROTECTED] (Eric W. Biederman) Date: Thu, 21 Jun 2007 13:08:12 -0600 However this just seems to allow a card to decode multiple mac addresses which in some oddball load balancing configurations may actually be useful, but it seems fairly limited. Do you have a specific use case you envision for this multiple mac functionality? Virtualization. If you can't tell the ethernet card that more than 1 MAC address are for it, you have to turn the thing into promiscuous mode. Networking on virtualization is typically done by giving each guest a unique MAC address, the guests have a virtual network device that connects to the control node (or dom0 in Xen parlace) and/or other guests. The control node has a switch that routes the packets from the guests either to other guests or out the real ethernet interface. Each guest gets a unique MAC so that the switch can know which guest an incoming packet is for. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC NET 00/02]: Secondary unicast address support
Eric W. Biederman wrote: I'm trying to understand what the point of this patch is. In once sense I find the concept of filtering and listening for multiple mac addresses very interesting, especially if we could break out different streams of traffic by destination mac address into separate network devices. This would remove the need to any kind of ethernet tunnel and makes multiple network namespaces much more pleasant. However this just seems to allow a card to decode multiple mac addresses which in some oddball load balancing configurations may actually be useful, but it seems fairly limited. Do you have a specific use case you envision for this multiple mac functionality? Yes, please see the MACVLAN patch I posted one or two days earlier. 8021q can also make use of it and Dave mentioned some virtualization devices want this as well. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC NET 00/02]: Secondary unicast address support
Patrick McHardy [EMAIL PROTECTED] writes: Eric W. Biederman wrote: I'm trying to understand what the point of this patch is. In once sense I find the concept of filtering and listening for multiple mac addresses very interesting, especially if we could break out different streams of traffic by destination mac address into separate network devices. This would remove the need to any kind of ethernet tunnel and makes multiple network namespaces much more pleasant. However this just seems to allow a card to decode multiple mac addresses which in some oddball load balancing configurations may actually be useful, but it seems fairly limited. Do you have a specific use case you envision for this multiple mac functionality? Yes, please see the MACVLAN patch I posted one or two days earlier. Thanks. That is what I was envisioning. I keep suspecting one of the cool multi-rx queue nics my start doing some of the demux in hardware. But whatever if it works and is relatively fast it is good enough for me. 8021q can also make use of it and Dave mentioned some virtualization devices want this as well. Right makes sense. And ethernet bridging (which is the general case of the virtualization Dave mentioned should also be able to take advantage of multiple unicast addresses). So this definitely make sense. Have you done any performance testing with the macvlan code? With the ethernet tunnel device we keep getting copied unicast packets on some path or other which slowed things down. Simply not doing the firewalling until the packets have made it through the macvlan device should help here. For the macvlan code do we need to do anything special if we transmit to a mac we would normally receive? Another unicast mac of the same nic for example. For the macvlan hash you just use an upper byte. Is that just a simple starting place, or do we not need a more complex hash. Eric - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC NET 00/02]: Secondary unicast address support
[EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] (Eric W. Biederman) Date: Thu, 21 Jun 2007 13:08:12 -0600 However this just seems to allow a card to decode multiple mac addresses which in some oddball load balancing configurations may actually be useful, but it seems fairly limited. Do you have a specific use case you envision for this multiple mac functionality? Virtualization. If you can't tell the ethernet card that more than 1 MAC address are for it, you have to turn the thing into promiscuous mode. Networking on virtualization is typically done by giving each guest a unique MAC address, the guests have a virtual network device that connects to the control node (or dom0 in Xen parlace) and/or other guests. The control node has a switch that routes the packets from the guests either to other guests or out the real ethernet interface. Each guest gets a unique MAC so that the switch can know which guest an incoming packet is for. The same software switch could also throw away the excess frames that promiscuous mode would have admitted. Unless the misdirected frames were common it would not seem to be a major CPU burden. Keep in mind that the only MAC addresses that would have been transmitted are the ones that the input filter would have listed. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC NET 00/02]: Secondary unicast address support
Eric W. Biederman wrote: Patrick McHardy [EMAIL PROTECTED] writes: Eric W. Biederman wrote: I'm trying to understand what the point of this patch is. In once sense I find the concept of filtering and listening for multiple mac addresses very interesting, especially if we could break out different streams of traffic by destination mac address into separate network devices. This would remove the need to any kind of ethernet tunnel and makes multiple network namespaces much more pleasant. However this just seems to allow a card to decode multiple mac addresses which in some oddball load balancing configurations may actually be useful, but it seems fairly limited. Do you have a specific use case you envision for this multiple mac functionality? Yes, please see the MACVLAN patch I posted one or two days earlier. Thanks. That is what I was envisioning. I keep suspecting one of the cool multi-rx queue nics my start doing some of the demux in hardware. But whatever if it works and is relatively fast it is good enough for me. When NICs support that I guess they the macvlan driver could be adapted to take advantage of that. 8021q can also make use of it and Dave mentioned some virtualization devices want this as well. Right makes sense. And ethernet bridging (which is the general case of the virtualization Dave mentioned should also be able to take advantage of multiple unicast addresses). So this definitely make sense. It needs promiscous mode to learn, so I'm not sure how much this will help bridging. Have you done any performance testing with the macvlan code? With the ethernet tunnel device we keep getting copied unicast packets on some path or other which slowed things down. Simply not doing the firewalling until the packets have made it through the macvlan device should help here. Performance should be at least as good as on a bridge device since the macvlan driver does basically nothing and uses the same functions for receiving and sending packets. For the macvlan code do we need to do anything special if we transmit to a mac we would normally receive? Another unicast mac of the same nic for example. That doesn't happen under normal circumstances. I don't believe it would work. For the macvlan hash you just use an upper byte. Is that just a simple starting place, or do we not need a more complex hash. It comes from the original code, I think it should be good enough. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC NET 00/02]: Secondary unicast address support
Eric W. Biederman wrote: For the macvlan hash you just use an upper byte. Is that just a simple starting place, or do we not need a more complex hash. That gave me an idea, since the default addresses are random anyway I'm now using an incrementing counter for the upper byte. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC NET 00/02]: Secondary unicast address support
Patrick McHardy wrote: Eric W. Biederman wrote: For the macvlan hash you just use an upper byte. Is that just a simple starting place, or do we not need a more complex hash. That gave me an idea, since the default addresses are random anyway I'm now using an incrementing counter for the upper byte. Is there not a (relatively) easy way to hash the entire 6 bytes? I'd prefer to be able to set the MACs to anything I want, without worrying about trivially hitting a worst-case hash scenario. Thanks, Ben - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC NET 00/02]: Secondary unicast address support
Patrick McHardy wrote: Eric W. Biederman wrote: For the macvlan code do we need to do anything special if we transmit to a mac we would normally receive? Another unicast mac of the same nic for example. That doesn't happen under normal circumstances. I don't believe it would work. Assuming you mean you want to send between two mac-vlans on the same physical nic... This can work if your mac-vlans are on different subnets and you are routing between them (and if you have my send-to-self patch or have another way to let a system send packets to itself). A normal ethernet switch will NOT turn a packet around on the same interface it was received, so that is why you must have them on different subnets and have a router in between. For sending directly to yourself, something like the 'veth' driver is probably more useful. For the macvlan hash you just use an upper byte. Is that just a simple starting place, or do we not need a more complex hash. It comes from the original code, I think it should be good enough. Ahhh, I knew my hash was lame for some reason! Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC NET 00/02]: Secondary unicast address support
Ben Greear [EMAIL PROTECTED] writes: Patrick McHardy wrote: Eric W. Biederman wrote: For the macvlan code do we need to do anything special if we transmit to a mac we would normally receive? Another unicast mac of the same nic for example. That doesn't happen under normal circumstances. I don't believe it would work. Assuming you mean you want to send between two mac-vlans on the same physical nic... This can work if your mac-vlans are on different subnets and you are routing between them (and if you have my send-to-self patch or have another way to let a system send packets to itself). Ok. I didn't know if you could trigger this case without without having then endpoints in separate namespaces. I was suspecting the routing code would realize what we were doing realize the route is local and route through lo. A normal ethernet switch will NOT turn a packet around on the same interface it was received, so that is why you must have them on different subnets and have a router in between. Yes. That is essentially the configuration I was wondering about. For sending directly to yourself, something like the 'veth' driver is probably more useful. True. And I think it has a place. However the common case with the tunnel devices is to just hook them all up to an ethernet bridge as well as a real ethernet device. The far ends of the ethernet tunnels are dropped into different namespaces. Which gets a very similar effect to the mac vlan code. I'm just wondering if I can not setup an ethernet tunnel device when my primary purpose is to talk to the outside world, but occasionally want a little in the box traffic. Eric - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
