Re: [B.A.T.M.A.N.] [PATCH] batman-adv: Only copy skb data for multiple broadcasts

[Sven Eckelmann <sven.eckelmann@gmx.de>]

On Sunday 01 August 2010 17:28:53 Marek Lindner wrote:
> On Saturday 24 July 2010 00:14:29 Sven Eckelmann wrote:
> > batman-adv tries to resend broadcasts on all interfaces up to three
> > times. For each round and each interface it must provide a skb which
> > gets consumed by the sending function.
> > 
> > It is unnecessary to copy the data of each broadcast because the actual
> > data is either not shared or already copied by add_bcast_packet_to_list.
> > So it is enough to just copy the skb control data
> 
> I think the reason to call skb_copy() is the following dev_queue_xmit()
> call which will consume the given skb. If we consider a case of having 3
> interfaces all 3 cloned skbs point to the same data while going out via
> different interfaces ? I wonder whether that can work ?!

Can we try to explain what we think will happen? I would assume following:
 * payload is there in skb
 * skb will be cloned to skb1 (not copied, so the actual data is shared)
 * send_skb_packet will be called and a ethernet header with the actual
   address is added to the data of skb and skb1 - only skb1 will know about
   that new stuff and point to the new data
 * skb1 will be consumed by dev_queue_xmit (not the data, because the refcount
   will not become 0)
 * next if will be processed
 * skb (without the knowledge about the ethernet header stuff) will be cloned
   to skb1
 * send_skb_packet will be called with skb1 and new, personalized ethernet
   header is added
 * skb1 will be consumed by dev_queue_xmit
 * and so on

So the data will be touched, but only the part which is not "know" by the 
initial/original skb. It is not accessed at the same time by other 
cpus/threads/whatever. The skb control data is only cloned because it will be 
consumed and changed in a way which would affect other batman-ifs.

So I would assume that this works with skb_clone instead of skb_copy.

Best regards,
	Sven