[TriLUG] scheduling of reception of packets by a "protocol stack"

[James Olin Oden]

So does this answer the context switch issue they are trying to
avoid...essentially they are dong in kernel filtering for better
performance?   Course I wonder if the packet filter interface in the
kernel might be the better way to implement this.

Thanks...james

On Sat, Jun 14, 2008 at 11:47 AM, Reginald Reed <reginald.reed at gmail.com> wrote:
> Howdy James!
>
> Have they considered using zero copy drivers + user protocol stacks?
> This maps a section of ram that the Ethernet port dma's directly
> into.  You then have full control to do whatever you want in userspace.
>
> Sent from my iPhone
>
> On Jun 14, 2008, at 11:13 AM, "James Olin Oden" <james.oden at gmail.com>
> wrote:
>
>> Hi All,
>>
>> So here is the really simple high level problem I'm seeing.  A group
>> of developers have developed a protocol that sits on top of an
>> ethernet driver (e1000).  When the ethernet driver hands off the
>> packet it received to the protocol it seems to be always running the
>> protocols callback on the same processor its  bottom end received the
>> packet upon.  In this case due to some heavy in kernel processing (I
>> know bad idea, but sometimes you end up here) this ends up saturating
>> the processing capability of this lone processor.
>>
>> So here are my questions:
>>
>>   1) How does the kernel schedule the hand off of a packet to a
>> protocol from its layer 2 drivers?
>>   2) Where is the code that handles this scheduling in the kernel
>> source?
>>   3) Where else might I ask this question?  I'm trying to avoid the
>> linux kernel list for various reasons, but if there is a smaller
>>       list where newbies to linux kernel networking might ask
>> questions I'd be pleased to know that.
>>
>>
>> Thanks...james
>> --
>> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
>> TriLUG FAQ  : http://www.trilug.org/wiki/Frequently_Asked_Questions
> --
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG FAQ  : http://www.trilug.org/wiki/Frequently_Asked_Questions
>