[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <478CCC95.8030405@hp.com>
Date: Tue, 15 Jan 2008 10:09:09 -0500
From: Vlad Yasevich <vladislav.yasevich@...com>
To: Chris Friesen <cfriesen@...tel.com>
Cc: Eric Dumazet <dada1@...mosbay.com>, Ray Lee <ray-lk@...rabbit.org>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: questions on NAPI processing latency and dropped network packets
Chris Friesen wrote:
> Eric Dumazet wrote:
>> Chris Friesen a écrit :
>
>>> Based on the profiling information we're spending time in
>>> sctp_endpoint_lookup_assoc() which doesn't actually use hashes, so I
>>> can't see how the hash would be related. I'm pretty new to SCTP
>>> though, so I may be missing something.
>>
>> Well, it does use hashes :)
>>
>> hash = sctp_assoc_hashfn(ep->base.bind_addr.port, rport);
>> head = &sctp_assoc_hashtable[hash];
>> read_lock(&head->lock);
>> sctp_for_each_hentry(epb, node, &head->chain) {
>> /* maybe your machine is traversing here a *really* long
>> chain */
>> }
>
>
> The latest released kernel doesn't have this code, it was only added in
> November. The SCTP maintainer just pointed me to the patch, and made
> some other suggestions as well.
>
Yes, the hash code only got added to 2.6.24. Before that, it was
a linear list traversal which sucked.
I need to take a look at the locking to see if we can further reduce
the time that bottom half is disabled.
-vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists