From: Rusty Russell <rusty@rustcorp.com.au>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, shemminger@linux-foundation.org,
jgarzik@pobox.com, hadi@cyberus.ca
Subject: Re: [PATCH RFX]: napi_struct V3
Date: Wed, 25 Jul 2007 15:09:55 +1000 [thread overview]
Message-ID: <1185340196.1803.482.camel@localhost.localdomain> (raw)
In-Reply-To: <20070724.212951.70218044.davem@davemloft.net>
On Tue, 2007-07-24 at 21:29 -0700, David Miller wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
> Date: Wed, 25 Jul 2007 12:33:14 +1000
>
> > Maybe by adding YA state bit? Hold on, this might get ugly...
> >
> > Say netif_rx_schedule_prep() sets the MORE_TODO bit (atomically instead
> > of setting __LINK_STATE_RX_SCHED) if it's going to fail, and
> > netif_rx_complete() returns 0 if it was set, or 1 if it's OK. Now
> > callers do:
> >
> > reenable_interrupts();
> > if (rx_pending() || !netif_rx_complete(netdev, napi))
> > disable_interrupts();
>
> This is an interesting idea, and would work, but the extra atomics
> for something that 2 or 3 drivers actually need.... unless I
> misunderstand your suggestion?
Well, netif_rx_schedule_prep() becomes a cmpxchg instead of a
test_and_set_bit:
/* We either set MORE_TODO or RX_SCHED. */
unsigned long state;
again:
state = napi->state;
if (!(state & __LINK_STATE_RX_SCHED)) {
if (cmpxchg(&napi->state, state, state|__LINK_STATE_RX_SCHED) == state)
return 1;
} else {
if (cmpxchg(&napi->state, state, state|__LINK_STATE_MORE_TODO) == state)
return 0;
}
goto again;
netif_rx_complete would need something more complex... hmm...
unsigned long state;
again:
state = napi->state;
if (state & __LINK_STATE_MORE_TODO)
return 0;
list_del(&napi->poll_list);
if (cmpxchg(&napi->state, state, state & ~__LINK_STATE_RX_SCHED) == state)
return 1;
list_add_tail(napi->poll_list, &__get_cpu_var(softnet_data).poll_list);
goto again;
Not pretty 8(
Rusty.
if (
next prev parent reply other threads:[~2007-07-25 5:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-24 4:07 [PATCH RFX]: napi_struct V3 David Miller
2007-07-24 4:47 ` Rusty Russell
2007-07-24 5:47 ` David Miller
2007-07-24 6:21 ` Rusty Russell
2007-07-25 0:45 ` David Miller
2007-07-25 1:15 ` Rusty Russell
2007-07-25 1:47 ` David Miller
2007-07-25 2:33 ` Rusty Russell
2007-07-25 4:29 ` David Miller
2007-07-25 5:09 ` Rusty Russell [this message]
2007-07-25 5:12 ` David Miller
2007-07-25 5:10 ` David Miller
2007-07-24 7:12 ` Francois Romieu
2007-07-24 7:33 ` Jeff Garzik
2007-07-24 7:35 ` David Miller
2007-07-28 15:21 ` Roland Dreier
2007-07-29 5:30 ` 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=1185340196.1803.482.camel@localhost.localdomain \
--to=rusty@rustcorp.com.au \
--cc=davem@davemloft.net \
--cc=hadi@cyberus.ca \
--cc=jgarzik@pobox.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.org \
/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.