On Mon, 2008-05-05 at 16:24 -0700, David Miller wrote:
quoted text > > Also, should there be some sort of timer that resets the rx_alloc_extra
> > again so that when you bridge it once with p54 (needs heaps of headroom=
)
quoted text > > you don't suffer forever?
>=20
> We're talking about, what, up to 128 bytes or something like that?
> If you're bridging over your wireless device you've already invested
> in assuming those kinds of costs.
About that much at most, yeah. But if you then decide that you don't
want to bridge wireless after all... anyway doesn't matter, was just a
thought.
quoted text > I don't think this aspect is really worth worrying about. The current
> behavior is so much incredibly worse. :-)
That's true.
quoted text > > > @@ -255,11 +255,12 @@ struct sk_buff *__netdev_alloc_skb(struct net_d=
evice *dev,
quoted text > > > unsigned int length, gfp_t gfp_mask)
> > > {
> > > int node =3D dev->dev.parent ? dev_to_node(dev->dev.parent) : -1;
> > > + unsigned int extra =3D dev->rx_alloc_extra + NET_SKB_PAD;
> > > struct sk_buff *skb;
> > > =20
> > > - skb =3D __alloc_skb(length + NET_SKB_PAD, gfp_mask, 0, node);
> > > + skb =3D __alloc_skb(length + extra, gfp_mask, 0, node);
> > > if (likely(skb)) {
> > > - skb_reserve(skb, NET_SKB_PAD);
> > > + skb_reserve(skb, extra);
> >=20
> > Doesn't that break alignment though?
>=20
> Good catch, we'll have to align the rx_alloc_extra to some modulus or
> similar. Ideally, at the spot where rx_alloc_extra is set instead
> of here.
Yeah, it just has to be a multiple of four I think.
johannes
