Re: OFFTOPIC: Regarding NT vs Linux

Alan Cox (
Thu, 25 Sep 1997 17:31:00 +0100 (BST)

> Each SKB has two modes of operation, a "traditional" mode (ie. how
> they work right now) and a "sharing" mode where you roughly have a ptr
> to the protocol header in kernel space and pointer(s) to the user
> buffer data that gets slapped at the end.

Thats a pretty good description of ATM for Linux

> c) If not go to (5)

c2) check the device isnt busy

> is the same, you're saving memory. But I think it will be faster as
> well because in many cases the user's copy will be in the L2 cache so
> the checksum will be taking hits.

RX isnt that bad either _if_ the card can checksum. Think

packet arrives

1. DMA devices

allocate full sized sk_buff. DMA header to it. If we can find the
checksum status store that.
Mark buffer data unlocked, store a skb->getdata function, fire

protocol layer
unlock data(buffer)
queue for user

user, dequeue, lock data dma to user space if need be. Because we
alloced the space the card can DMA the memory from internal buffers
ready if it has too to make room - hence lock/unlock data

For UDP you can pull further dirties for checksumless cards by
doing the DMA to user, checking if it has a bad checksum then looping

2. Memory devices

allocate an sk_buff of full size. Point its data into the cards
ring buffer. lock the data. Tie the skb to the ring entry in the

protocol layer
unlock data
queue for user

user, dequeue, lock data
normal skb copy to user but coming from ring buffer

If the ring is filling then the card driver can reclaim all unlocked
buffers by putting the data into the real sk-buff memory we allocated
and flipping the pointers.

Ultimately for RX most of the protocol engine needs to be in the user context.
Its literally a demux, queue and kick user on the bh path. That'll help SMP
scaling too. The user thread then does

process headers
copy_and_checksum to user if need be
forget_we_saw_it --^

We may need to promote the threads to realtime priority while doing that