Matt Mackall <mpm@xxxxxxxxxxx> wrote: >On Mon, 2010-03-22 at 04:17 -0400, Amerigo Wang wrote: >> Based on Andy's work, but I modify a lot. >> >> Similar to the patch for bridge, this patch does: >> >> 1) implement the 4 methods to support netpoll for bonding; >> >> 2) modify netpoll during forwarding packets in bonding; >> >> 3) disable netpoll support of bridge when a netpoll-unabled device >> is added to bonding; >> >> 4) enable netpoll support when all underlying devices support netpoll. > >Again, not sure if this is the right policy. Seems to me that on a >bonding device we should simply pick an interface to send netpoll >messages on, without reference to balancing, etc. Thus, if any of the >bonded devices supports polling, it should work. For some of the modes, the above is pretty straighforward. Others, 802.3ad and balance-alb, are a bit more complicated. The risk is that the network peers and switches may see the same MAC address on multiple ports, or different MAC addresses for the same IP address. To implement the above suggestion, I think a "current netpoll slave" would have to be tracked, and kept up to date (as slaves become active or inactive, etc). Reusing the existing "current active slave" won't work for the case that the active slave is not netpoll-capable, but a different slave is; also, not all modes use the current active slave. In 802.3ad, the "current netpoll slave" selector will have to poke into the aggregator status to choose the netpoll slave. It's not a simple matter of picking one and then sticking with it forever; if the aggregator containing the netpoll slave is deactivated, then peers may not receive the traffic, etc. In the active-backup mode, only the active slave can send or receive, so if it's not netpoll capable, but a backup slave is, you're still out of luck (unless netpoll awareness is added to the "best slave" selection logic, and even then it'd have to be a secondary criteria). Or, the inactive slave can be transmitted on, but if the same MAC comes out of the active and a backup slave, it can confuse switches. In one mode (balance-alb), slaves keep their own MAC addresses, and are matched with peers. Bypassing the balance algorithm could again confuse peers or switches, who could see two MAC addresses for the same IP address, if netpoll traffic goes out a different slave than the balance algorithm picks for the same destination. I think, then, the question becomes: is this extra complexity worth it to cover the cases of netpoll over bonding wherein one or more slaves don't support netpoll? How many network drivers don't support netpoll nowadays? -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@xxxxxxxxxx _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
