svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Adrian Chadd]

On 20 January 2015 at 06:25, Ed Maste <emaste at freebsd.org> wrote:
> On 20 January 2015 at 04:37, Hans Petter Selasky <hps at selasky.org> wrote:
>>
>> It is not very hard to update existing callout clients and you can do it
>> too, if you need the extra bits of performance.
>
> Hi Hans Petter,
>
> The issue here is that the onus is on the one changing a KPI to
> support its consumers through the transition. This doesn't necessarily
> mean doing all of the work. But the KPI changes, and techniques for
> adapting to them, need to be communicated very well in advance of the
> change arriving.
>
> I appreciate that you have a patch for TCP in review now - but having
> Adrian encounter a huge TCP performance regression is an unfortunate
> way to discover this issue.

I'm +1 on the "think it's the right, clean solution for the callout
stuff" as I've done this stuff in userland a few times and it gets
hairy very quickly when you try to support multiple ways to schedule,
cancel and migrate events from arbitrary CPUs.

I'm -1 on the rapid change without fixing other consumers, but I'm
definitely +1 on the quick help from Hans on it. The TCP patch will
need some closer review by people who have recently worked on the TCP
stack and locking. I'll try to get the Verisign developers looped in
as they touched this stuff recently.

I do think we could do with a debugging print for now to catch
situations which need migrating. The callout API doesn't tell you that
it did or didn't migrate an event to another CPU and it could make for
some performance unpredictability.



-a