[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAsGZS7rUBMW6JK5q2U=7oJy7s2jL0QHAL2z-+9Rm+yM1a5_Kg@mail.gmail.com>
Date: Tue, 27 Mar 2012 14:39:29 -0400
From: chetan loke <loke.chetan@...il.com>
To: Richard Cochran <richardcochran@...il.com>
Cc: "Keller, Jacob E" <jacob.e.keller@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"e1000-devel@...ts.sourceforge.net"
<e1000-devel@...ts.sourceforge.net>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"Ronciak, John" <john.ronciak@...el.com>,
"john.stultz@...aro.org" <john.stultz@...aro.org>,
"tglx@...utronix.de" <tglx@...utronix.de>
Subject: Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the
timecompare method
On Tue, Mar 27, 2012 at 11:33 AM, Richard Cochran
<richardcochran@...il.com> wrote:
> On Mon, Mar 26, 2012 at 01:11:32PM -0400, chetan loke wrote:
>>
>> Why isn't ioctl-rate limiting acceptable?
>
> Let me turn the question around.
>
> What other kernel subsystem rate limits ioctls?
>
netdev needs to worry about reaching the host via ethernet. If you
lose SCSI LUNs because you are pounding those mailbox cmds to get that
temperature status from the HBA then who the heck cares? I mean we do
but we can reach the host via it's mgmt-IP and look at it. From what I
can see in SCSI for example, control commands are normally issued in
separate paths by the driver and don't choke the fast path. Those
completions are asynchronous like everything else and do NOT contend
with the Rx/Tx path.
May be I'm paranoid but let's wait for Intel(Jake) to run the ioctl test.
Chetan
--
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