Thread (8 messages) 8 messages, 5 authors, 2010-02-04

Re: [RFC] NAPI as kobject proposal

From: David Daney <hidden>
Date: 2010-02-03 21:54:28

Ben Hutchings wrote:
On Fri, 2010-01-29 at 10:18 -0800, Stephen Hemminger wrote:
quoted
The NAPI interface structure in current kernels is managed by the driver.
As part of receive packet steering there is a requirement to add an
additional parameter to this for the CPU map. And this map needs to
have an API to set it.

The right way to do this in the kernel model is to make NAPI into
a kobject and associate it back with the network device (parent).
This isn't wildly difficult but does change some of the API for
network device drivers because:
  1. They need to handle another possible error on setup
  2. NAPI object needs to be dynamically allocated
     separately (not as part of netdev_priv)
  3. Driver should pass index that can be uses as part of
     name (easier than scanning)

Eventually, there will be:
  /sys/class/net/eth0/napi0/
                            weight
                            cpumap
I think the NAPI objects should be created as children of a bus device
and then linked from the net device directories, e.g.

/sys/devices/.../ net/eth0/
                           napi0 -> ../../napi/napi0
                      eth1/
                           napi0 -> ../../napi/napi0
                  napi/napi0/
                             weight
                             cpumap
This seems right.

Some drivers have a single napi object logically associated with 
multiple interfaces.  Although the current architecture forces us to 
associate the napi object with a single net_device, it would be nice to 
move towards something that allows sharing a napi object between 
multiple devices.

David Daney
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help