: Secondary unicast address support

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.

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?

From: [email protected] (Eric W. Biederman)
Date: Thu, 21 Jun 2007 13:08:12 -0600

Quoted 6 lines

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.

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?

Quoted 12 lines · Eric W. Biederman

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.

Quoted 3 lines

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.

Quoted 18 lines · Patrick McHardy

Quoted 16 lines · Eric W. Biederman

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?

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 3 lines · Eric W. Biederman

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.

Quoted 4 lines

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.

Quoted 8 lines · Patrick McHardy

Quoted 3 lines · Eric W. Biederman

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.

Quoted 10 lines · Ben Greear

Quoted 6 lines · Patrick McHardy

Quoted 3 lines · Eric W. Biederman

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...

Quoted 3 lines

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.

Quoted 4 lines

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.

Quoted 2 lines

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

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.

Quoted 3 lines · Eric W. Biederman

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

Quoted 7 lines · Patrick McHardy

Quoted 3 lines · Eric W. Biederman

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.

Quoted 2 lines

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.