This patch implements an optimization I proposed a long time ago. gettimeofday can be quite costly and it currently is on the fast path of every packet. Normally the packet time stamp is not needed (
Andi Kleen wrote: This patch implements an optimization I proposed a long time ago. gettimeofday can be quite costly and it currently is on the fast path of every packet. Normally the packet time sta
Hi Andi, I suspect this breaks proxy arp/ndisc! The arp/ndisc requests are queued up for a random time before being processed by the proxy. Check out pneigh_enqueue() in net/core/neighbour.c for deta
Ok, thanks for clarifying this. I guessed the intention wrong then. A better way may be to just add a new skb flag for this that is managed by the arp code? Comments? -Andi
I guess that's all right. There just doesn't seem to be any general flag field in sk_buff that we might use at this moment. Should one be added, or should we just hide the flag inside the cb field us
Andi Kleen wrote: On Wed, Mar 31, 2004 at 05:24:47PM +0300, Ville Nuorvala wrote: There just doesn't seem to be any general flag field in sk_buff that we might use at this moment. Should one be added
Andi Kleen wrote: Why not add a 32-bit field to the skb to handle various flag needs going forward? That is what ->cb already is From the comments, it appears each layer can write over these, and sin
This patch implements an optimization I proposed a long time ago. gettimeofday can be quite costly and it currently is on the fast path of every packet. Normally the packet time stamp is not needed (
Andi Kleen wrote: This patch implements an optimization I proposed a long time ago. gettimeofday can be quite costly and it currently is on the fast path of every packet. Normally the packet time sta
Hi Andi, I suspect this breaks proxy arp/ndisc! The arp/ndisc requests are queued up for a random time before being processed by the proxy. Check out pneigh_enqueue() in net/core/neighbour.c for deta
Ok, thanks for clarifying this. I guessed the intention wrong then. A better way may be to just add a new skb flag for this that is managed by the arp code? Comments? -Andi
I guess that's all right. There just doesn't seem to be any general flag field in sk_buff that we might use at this moment. Should one be added, or should we just hide the flag inside the cb field us
There just doesn't seem to be any general flag field in sk_buff that we might use at this moment. Should one be added, or should we just hide the flag inside the cb field using the likes of inet_skb
Why not add a 32-bit field to the skb to handle various flag needs going forward? That is what ->cb already is From the comments, it appears each layer can write over these, and since it's just a bl