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

Re: [RFC] NAPI as kobject proposal

From: David Miller <davem@davemloft.net>
Date: 2010-02-04 01:32:51

From: Stephen Hemminger <redacted>
Date: Fri, 29 Jan 2010 10:18:39 -0800
As part of receive packet steering there is a requirement to add an
additional parameter to this for the CPU map.
Hmmm, where did this come from?

The RPS maps are per-device.

I think I vaguely recall you "suggesting" that the RPS maps become
per-NAPI.

But, firstly, I didn't see any movement in that part of the
discussion.

And, secondly, I don't think this makes any sense at all.

Things are already overly complicated as it is.  Having the user know
what traffic goes to a particular RX queue (ie. NAPI instance) and set
the RPS map in some way specific to that RX queue is over the top.

If the issue is the case of sharing a NAPI instance between two
devices, there are a few other ways to deal with this.

One I would suggest is to simply clone the RPS map amongst the
devices sharing a NAPI instance.

I currently see NAPI kobjects is just an over-abstraction for a
perceived need rather than a real one.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help