[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OF4096F552.5B89C6BA-ON65257359.0016534B-65257359.0016C2D0@in.ibm.com>
Date: Mon, 17 Sep 2007 09:38:36 +0530
From: Krishna Kumar2 <krkumar2@...ibm.com>
To: David Miller <davem@...emloft.net>
Cc: gaagaan@...il.com, general@...ts.openfabrics.org, hadi@...erus.ca,
herbert@...dor.apana.org.au, jagana@...ibm.com, jeff@...zik.org,
johnpol@....mipt.ru, kaber@...sh.net, kumarkr@...ux.ibm.com,
mcarlson@...adcom.com, mchan@...adcom.com, netdev@...r.kernel.org,
peter.p.waskiewicz.jr@...el.com, randy.dunlap@...cle.com,
rdreier@...co.com, rick.jones2@...com, Robert.Olsson@...a.slu.se,
shemminger@...ux-foundation.org, sri@...ibm.com, tgraf@...g.ch,
xma@...ibm.com
Subject: Re: [PATCH 0/10 REV5] Implement skb batching and support in IPoIB/E1000
Hi Dave,
David Miller <davem@...emloft.net> wrote on 09/17/2007 04:47:48 AM:
> The only major complaint I have about this patch series is that
> the IPoIB part should just be one big changeset. Otherwise the
> tree is not bisectable, for example the initial ipoib header file
> change breaks the build.
Right, I will change it accordingly.
> On a lower priority, I question the indirection of skb_blist by making
> it a pointer. For what? Saving 12 bytes on 64-bit? That kmalloc()'d
> thing is a nearly guarenteed cache and/or TLB miss. Just inline the
> thing, we generally don't do crap like this anywhere else.
The intention was to avoid having two flags (one that driver supports
batching and second to indicate that batching is on/off). So I could test
skb_blist as an indication of whether batching is on/off. But your point
on cache miss is absolutely correct, and I will change this part to be
inline.
thanks,
- KK
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists