jamal writes:
> Essentially the approach would be the same as Robert's old recycle patch
> where he doesnt recycle certain skbs - the only difference being in the
> case of forwarding, the recycle is done asynchronously at EOT whereas
> this is done synchronously upon return from host path.
> The beauty of the approach is you dont have to worry about recycling on
> the wrong CPU ;-> (which has been a big problem for forwarding path)
> I have to chime in and say for the host stack - I like it ;->
No we don't solve any problems for forwarding but as Dave pointed out
we can do nice things. Instead of dropping skb is case of failures or
netfilter etc we can reuse the skb and if the skb is consumed within
the RX softirq we can just return it driver.
You did the feedback mechanism NET_RX_XX stuff six years ago.
Now it can possible used :)
A practical problem is how maintain compatibility with the current
behavior which defaults to NET_RX_SKB_CONSUMED.
An new driver entry point? And can we increase skb->users to delay
skb destruction until the driver got the indication back?
So the driver will do the final kfree and not in the protocol layers
as now? This to avoid massive code changes.
Thoughts?
Cheers
--ro
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
