On Sun, May 04, 2008 at 02:52:41PM +0200, Johannes Berg wrote:Actually this is not as bad as it sounds. Since you're constructing the hardware header anyway, it may turn out to be easier to tack on the Ethernet header while you're at it. Please note that the hardware cache is not the same as the neighbour cache. Just because you lose the hardware cache doesn't mean that you'd lose the neighbour (ARP) cache. However, this would mean that you'd no longer have an Ethernet device which is both good and bad. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Dave Hansen | [RFC][PATCH 0/4] kernel-based checkpoint restart |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Eric Paris | [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning |
git: | |
| David Miller | Re: [GIT]: Networking |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
