On Fri, 2013-11-01 at 19:00 +0000, Zoltan Kiss wrote: > On 01/11/13 10:50, Ian Campbell wrote: > > Does this always avoid copying when bridging/openvswitching/forwarding > > (e.g. masquerading etc)? For both domU->domU and domU->physical NIC? > I've tested the domU->domU, domU->physical with bridge and openvswitch > usecase, and now I've created a new stat counter to see how often copy > happens (the callback's second parameter tells you whether the skb was > freed or copied). It doesn't do copy in all of these scenarios. > What do you mean by forwarding? The scenario when you use bridge and > iptables mangling with the packet, not just filtering?
I mean using L3 routing rather L2 bridging. Which might involve NAT/MASQUERADE or might just be normal IP routing. > > How does it deal with broadcast traffic? > Most of the real broadcast traffic actually small packets fit in the > PKT_PROT_LEN sized linear space, so it doesn't make any difference, > apart from doing a mapping before copy. But that will be eliminated > later on, I plan to add an incremental improvement to grant copy the > linear part. OK. If I were a malicious guest and decided to start sending out loads of huge broadcasts would that lead to a massive spike of activity in dom0? > I haven't spent too much time on that, but I couldn't find any broadcast > protocol which use large enough packets and easy to test, so I'm open to > ideas. I guess you could hack something up using raw sockets? > What I already know, skb_clone trigger a copy, and if the caller use the > original skb for every cloning, it will do several copy. I think that > could be fixed by using the first clone to do any further clones. Yes. I suppose doing this automatically might be an interesting extension to SKBTX_DEV_ZEROCOPY? Ian. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
