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

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

[Yannick Koehler]

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.

--
Yannick Koehler

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

[Eric Dumazet]

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...)