All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@vyatta.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Ben Hutchings <bhutchings@solarflare.com>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [RFC] NAPI as kobject proposal
Date: Wed, 3 Feb 2010 13:41:56 -0800	[thread overview]
Message-ID: <20100203134156.086e3e70@nehalam> (raw)
In-Reply-To: <20100203212641.GB30031@ZenIV.linux.org.uk>

On Wed, 3 Feb 2010 21:26:41 +0000
Al Viro <viro@ZenIV.linux.org.uk> wrote:

> On Wed, Feb 03, 2010 at 09:23:36PM +0000, Ben Hutchings wrote:
> > On Fri, 2010-01-29 at 10:18 -0800, Stephen Hemminger wrote:
> > > 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)
> 
> 4. Lifetime rules become oh-so-fscking-interesting?

My original proposal doesn't go far enough. I am doing a bigger
version that changes API to:
   napi_alloc / napi_release

The lifetime problem isn't that bad because the napi is a child
of network device object.  Make it a child bus object is a bigger
problem because then network device can come and go.

-- 

  reply	other threads:[~2010-02-03 21:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-29 18:18 [RFC] NAPI as kobject proposal Stephen Hemminger
2010-02-03 21:23 ` Ben Hutchings
2010-02-03 21:26   ` Al Viro
2010-02-03 21:41     ` Stephen Hemminger [this message]
2010-02-03 21:38   ` David Daney
2010-02-04  1:33 ` David Miller
2010-02-04  1:58   ` Stephen Hemminger
2010-02-04  2:17     ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100203134156.086e3e70@nehalam \
    --to=shemminger@vyatta.com \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.