how does user application call NAPI poll method of network device driver.
in [General Linux]
|
Prev: FC12 install gives init3, no Gnome, no network???
Next: hard links to files on other filesystems disallowed: why?
From: mcharon on 19 Feb 2010 20:46 I have read documents on the network device driver which explains about the NAPI poll method and how to implment the method but usually the documents (books) don't explain how the poll method gets invoked from the user application. is it the user space poll()/select() function that calls the driver's poll method? if so, how do i obtain the file descriptor needed for the poll()/select()? i have tried calling 'recvfrom' in the user app, using socket file decriptor, but that didn't call the poll method of the driver. thank you very much in advance.
From: Lew Pitcher on 20 Feb 2010 17:04 On Feb 19, 8:46 pm, mcharon <mcha...(a)gmail.com> wrote: > I have read documents on the network device driver which explains > about the NAPI poll method and how to implment the method but usually > the documents (books) don't explain > how the poll method gets invoked from the user application. Apparently, it doesn't. More specifically, the driver's poll() method is invoked from the Linux kernel's networking logic, and only if the driver has indicated that it /can/ be polled (through a driver-to-kernel netif_rx_schedule() call). There doesn't seem to be a userspace component to this; it is entirely a driver/kernel interface. > is it the user space poll()/select() function that calls the driver's > poll method? if so, > how do i obtain the file descriptor needed for the poll()/select()? Again, from what I read, the NAPI is only used between the network device driver and the kernel network logic to assist in speedy reception or transmission of packets. Incoming packets will be marshalled by the device driver and handed off to the kernel networking subsystem for analysis and distribution. Outgoing packets have already been handled by the kernel networking subsystem, and are ready to be put on the wire. In both cases (inbound and outbound), the application's access to the packets is completely independant from the kernel/driver NAPI processing. There should be no difference, at the application syscall level, as to how the packets are processed. The /only/ difference is in the kernel and the device driver, and that's not controllable from userspace. > i have tried calling 'recvfrom' in the user app, using socket file > decriptor, but that > didn't call the poll method of the driver. Are you sure that the drive has called the netif_rx_schedule() NAPI kernel API > thank you very much in advance.
From: David Schwartz on 21 Feb 2010 04:48 On Feb 19, 5:46 pm, mcharon <mcha...(a)gmail.com> wrote: > I have read documents on the network device driver which explains > about the NAPI poll method and how to implment the method but usually > the documents (books) don't explain > how the poll method gets invoked from the user application. It doesn't. The kernel calls the NAPI poll method if/when appropriate. > is it the user space poll()/select() function that calls the driver's > poll method? No, not at all. The user space poll/select is typically looking for things like packets to a particular UDP socket. This is nothing at all like the driver's poll method, which is for low-level packet availability. > if so, > how do i obtain the file descriptor needed for the poll()/select()? > i have tried calling 'recvfrom' in the user app, using socket file > decriptor, but that > didn't call the poll method of the driver. This question seems to be based on a misunderstanding. How the user- space code finds out about packets for its specific sockets has nothing whatsoever to do with how the kernel finds out that packets are available from a network interface. The kernel has to be listening even if no application is, and the kernel won't change how it interacts with a network card just because a user-space application checked its user-space socket differently. Network Card <-> Network Driver <-> Kernel <-> Protocol Drivers <-> Socket <-> Application NAP is over by the network driver to kernel interface. User-space calls like 'recvfrom' and 'select' are over at the socket layer. DS
From: mcharon on 21 Feb 2010 17:36
On Feb 21, 1:48 am, David Schwartz <dav...(a)webmaster.com> wrote: > On Feb 19, 5:46 pm, mcharon <mcha...(a)gmail.com> wrote: > > > I have read documents on the network device driver which explains > > about the NAPI poll method and how to implment the method but usually > > the documents (books) don't explain > > how the poll method gets invoked from the user application. > > It doesn't. The kernel calls the NAPI poll method if/when appropriate. > > > is it the user space poll()/select() function that calls the driver's > > poll method? > > No, not at all. The user space poll/select is typically looking for > things like packets to a particular UDP socket. This is nothing at all > like the driver's poll method, which is for low-level packet > availability. > > > if so, > > how do i obtain the file descriptor needed for the poll()/select()? > > i have tried calling 'recvfrom' in the user app, using socket file > > decriptor, but that > > didn't call the poll method of the driver. > > This question seems to be based on a misunderstanding. How the user- > space code finds out about packets for its specific sockets has > nothing whatsoever to do with how the kernel finds out that packets > are available from a network interface. The kernel has to be listening > even if no application is, and the kernel won't change how it > interacts with a network card just because a user-space application > checked its user-space socket differently. > > Network Card <-> Network Driver <-> Kernel <-> Protocol Drivers <-> > Socket <-> Application > > NAP is over by the network driver to kernel interface. User-space > calls like 'recvfrom' and 'select' are over at the socket layer. > > DS thank you for all of your responses. |