[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OFA7D22363.1BE2EB19-ON6525731E.0042AA56-6525731E.0042C514@in.ibm.com>
Date: Fri, 20 Jul 2007 17:39:18 +0530
From: Krishna Kumar2 <krkumar2@...ibm.com>
To: Patrick McHardy <kaber@...sh.net>
Cc: davem@...emloft.net, gaagaan@...il.com,
general@...ts.openfabrics.org, hadi@...erus.ca,
herbert@...dor.apana.org.au, jagana@...ibm.com, jeff@...zik.org,
johnpol@....mipt.ru, kumarkr@...ux.ibm.com, mcarlson@...adcom.com,
mchan@...adcom.com, netdev@...r.kernel.org,
peter.p.waskiewicz.jr@...el.com, rdreier@...co.com,
rick.jones2@...com, Robert.Olsson@...a.slu.se, sri@...ibm.com,
tgraf@...g.ch, xma@...ibm.com
Subject: Re: [PATCH 03/10] dev.c changes.
Patrick McHardy <kaber@...sh.net> wrote on 07/20/2007:
> I can't really argue about the numbers, but it seems to me that only
> devices which *usually* have a sufficient queue length will support
> this, and anyone setting the queue length of a gbit device to <16 is
> begging for trouble anyway. So it doesn't really seem worth to bloat
> the code for handling an insane configuration as long as it doesn't
> break.
Ah, I get your point now. So if driver sets BATCHING and user then sets
queue_len to (say) 4, then poor results are expected (and kernel doesn't
need to try fix it). Same for driver setting BATCHING when it's queue is
small in the first place, which no driver writer should do anyway. I think
it makes the code a lot easier too. Will update.
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