batman-adv: Only copy skb data for multiple broadcasts

  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

Signed-off-by: Sven Eckelmann <sven.eckelmann@gmx.de>
---
 batman-adv/send.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
  

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 ?!

Cheers,
Marek
  

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
  

Sven Eckelmann wrote:
> 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 ?!

We discussed that off the list. This part is addressed in
 [PATCH 1/7] batman-adv: Keep header writable and unshared

the problem we found was that our data is maybe still be queued somewhere 
after the dev_queue_xmit. This means that the header part is still be shared 
and we may not be able to change it in our new clone without side effects to 
the other skb. To prevent that we use skb_cow_head to ensure that our new 
added header doesn't interfere with skbs using the same data buffer.

This should reduce the overhead created by the skb_copy in many situations, 
but still allow us to freely write into the new pushed header area when the 
skb would otherwise be in a shared/cloned state.

Regards,
	Sven