[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02874ECE860811409154E81DA85FBB580DC04D@ORSMSX105.amr.corp.intel.com>
Date: Mon, 26 Mar 2012 18:56:44 +0000
From: "Keller, Jacob E" <jacob.e.keller@...el.com>
To: chetan loke <loke.chetan@...il.com>,
Richard Cochran <richardcochran@...il.com>
CC: "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
> -----Original Message-----
> From: chetan loke [mailto:loke.chetan@...il.com]
> Sent: Monday, March 26, 2012 10:12 AM
> To: Richard Cochran
> Cc: Keller, Jacob E; netdev@...r.kernel.org; e1000-
> devel@...ts.sourceforge.net; Kirsher, Jeffrey T; Ronciak, John;
> john.stultz@...aro.org; tglx@...utronix.de
> Subject: Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the
> timecompare method
>
> You are confusing 'blocking the driver's fast path' with
> performance/optimization etc. We cannot let user-space code jam the system.
> Kernel code should be designed such that
> bugs(intentional/unintentional) in user-space code cannot cause system wide
> adverse affects. Period.
>
I agree. But I also think a test case should be in order here. What actually
happens with a badly designed user app cramming ioctls. (Note that under most
system designs the ioctls require root access unless you change the default
permissions.)
> Does your existing design limit (ab)users from pounding the ioctls?
>
> As I mentioned earlier, it could be possible to take care of gettime and the
> driver's Rx/Tx path by using a mixture of locks/kernel-thread.
> But settime/adjtime still needs to be curbed.
>
I am curious how you see a kernel thread resolving the Tx/Rx issue? or is the
kernel thread being used by gettime? I don't believe we can wait for the Tx/Rx
path, because if we take too long the software sees it as a dropped timestamp.
Also we have a pointer to the skb which is free'd right after the call for
(rx/tx)hwtstamp so we can't just copy that pointer.
> Why isn't ioctl-rate limiting acceptable? Let's say an app that is trying to
> set/adj NIC counter is running on host side then how often would it need to
> read and correct/set/adj? once every msec(so 1000 times a second), once every
> 10 msec(100 times a second) etc?
>
> So, will pounding the ioctl 1000 times, while processing ~820K
> frames(1500 byte payload on 10G link) still cause a problem for the driver is
> what we would need to see. rate can also be a factor of link-speed(?).
>
> And we don't need 100 such apps. Only 1 app should be working in tandem with
> the NIC. If other apps fail then atleast the sysadmin or users would know
> someone else is (ab)using it.
How would we only allow one app? Any app with permissions could call the ioctls.
I do agree that having too many ioctls is a problem. Even in cases where PTP is
only enabled on a "trusted" system. Allowing the kernel to assume the system
is trusted means we introduce security holes. I am not sure of the right solution
or whether we need a different one, though. I am going to try and provide a test case
where someone hammers the ioctls in a loop, and see what happens.
>
>
> > Thanks,
> > Richard
>
> Chetan
Powered by blists - more mailing lists