Re: [PACTH] enable memory mapped access toethernet

["Paolo Abeni" <paolo.abeni () telecomitalia it>]

hello,

On Fri, 2007-12-14 at 10:32 -0800, Guy Harris wrote:
> My main concern is with mmapped access.  Presumably, with mmapped 
> access, there are still system calls that move a "these packets have 
> been read" pointer and that block until the "these packets have arrived" 
> pointer to move ahead of the "these packets have been read" pointer; if 
> that's the case, and if a select() or poll() will also check for the 
> "these packets have arrived" pointer being ahead of the "these packets 
> have been read" pointer, that will work.

The description you give is pretty mach what happen in the kernel code,
with the main difference that the incoming data can be processed even
without enforcing a FIFO logic. There are no known issues even with mmap
access.

To give a bit more details on kernel processing, a wait queue is
maintained for each reader. Whenever a new URB (the USB 'packet')
arrives and can be delivered to the user space process (there is free
space in the receive ring), the wait queue is signaled. The device
driver's poll() method, used to implement both poll() and select()
syscall, explicitly wait on said queue.

An ioctl is used to get the references to the arrived URBs and to
explicitly tell to the kernel which URBs has been processed by the
user-space, and thus are considered free.

ciao,

Paolo




--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If 
you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it 
immediately to the sender and delete the message. Should you have any questions, please contact us by replying to 
webmaster () telecomitalia it.

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------
                        
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.