Re: Multicast/Broadcast enhancement: SKB read-only with copy-on-write

[Eric Dumazet <eric.dumazet@gmail.com>]

On Mon, 2013-03-04 at 10:29 -0500, Yannick Koehler wrote:
> Hi,
> 
>   Recently I was working into the kernel area where the code handle
> broadcast/multicast in bridge logical interface for example.  It seems
> today inevitable that when we flood, the bridge code has to duplicate
> the full SKB, metadata as well as data, in order to transmit to each
> link under it.  I was wondering if there was way for the SKB system to
> support copy-on-write, such that, from a starting point, the SKB would
> be "frozen" into a read-only mode and then if someone wants to modify
> the SKB metadata/data it is done in a way to preserve the original SKB
> memory, as to ensure that after the SKB has been transmitted over that
> particular link, it can also be used without a full memory copy to be
> sent to subsequent link, simultaneously on multi-core/mutli-interface
> system.
> 
>   I am wondering at what level such work would be consider, is it
> relatively easy, does Linux have anything like that, is it major work,
> since pretty much everyone expect SKB data to be writable (like
> skb_may_pull could be used to obtain a specific client SKB version
> area).  It would probably require a new field in the SKB to indicate
> that this is a read-only/copy-on-write version of a specific "original
> SKB".
> 
>   Anyway, just wanted some thoughts/opinions on the topic regarding
> the scale of such a change.
> 

Current skb handling already provides this "read-only" and
"copy-on-write" management.

We only have to use the correct API where it matters, like
skb_share_check()

For an example, take a look at commit de063b7040dcd9
(bonding: remove packet cloning in recv_probe())

ARP packets for example could be handled in a read-only way.

(You dont really explain what particular problem you have,
ARP is only a guess...)