Messages in this thread |  | | Subject | Re: [PATCH net-next RFC 0/5] xen-netback: TX grant mapping instead of copy | From | Ian Campbell <> | Date | Thu, 7 Nov 2013 10:52:43 +0000 |
| |
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.
|  |