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
