Linhaifeng writes:
> On 2015/6/4 9:13, Rusty Russell wrote:
>> Linhaifeng writes:
>>> Hi,
>>>
>>> I'm a newbie and have a question about vring_new_virtqueue function.
>>>
>>> Why we set avail->flags to VRING_AVAIL_F_NO_INTERRUP
ks.
Hi Linhaifeng,
Not sure I understand your question, but I'll try to answer.
We don't set VRING_AVAIL_F_NO_INTERRUPT if there's a callback because we
want that callback called. Otherwise callback will never be used.
Cheers,
Rusty.
--
To unsubscribe from this list: send
certainly shouldn't hurt. Please push this out.
Acked-by: Rusty Russell <[EMAIL PROTECTED]>
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sunday 03 February 2008 17:15:02 Andrew Morton wrote:
> On Thu, 17 Jan 2008 17:57:58 +1100 Rusty Russell <[EMAIL PROTECTED]>
wrote:
> > I assume that these ancient network drivers were trying to find out if
> > an irq is available. eepro.c expecting +EBUSY was doubly w
Implement skb_partial_csum_set, for setting partial csums on untrusted packets.
Use it in virtio_net (replacing buggy version there), it's also going
to be used by TAP for partial csum support.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[E
On Thursday 24 January 2008 09:04:14 Andrew Morton wrote:
> > On Thu, 17 Jan 2008 17:59:58 +1100 Rusty Russell <[EMAIL PROTECTED]>
> If no driver is passing in args which will trigger this BUG, we presumably
> don't need the patch.
You're only thinking of current c
printf("%s ", known_flags[i].name);
}
}
if (features)
printf("(UNKNOWN %#x)", features);
printf("\n");
return 0;
}
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/net/tun.c
es of) GSO packets.
Note that there is no easy way to detect if these flags are supported:
see next patch.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/net/tun.c | 259 +++--
include/linux/if_tun.h |6 +
2 files changed
IPv6 or v4.
3) Rename VIRTIO_NET_F_NO_CSUM to VIRTIO_NET_F_CSUM (ie. means we do
checksumming).
4) Add csum and gso params to virtio_net to allow more testing.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/net/virtio_net.c | 32
in
On Tuesday 22 January 2008 21:36:30 Herbert Xu wrote:
> On Wed, Jan 16, 2008 at 03:19:03PM +1100, Rusty Russell wrote:
> > > > It's far easier to deal with GSO if we don't have to parse the packet
> > > > to figure out the header length. Add the field to the v
Is there any reason why these bugs should be treated gently? The
caller might not want to check NR_IRQS and IRQ_NOREQUEST cases, but
a NULL handler or NULL dev_id w/ shared are coding bugs.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
kernel/irq/manage.c |7 +++
1 file c
been found
earlier.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/net/3c503.c |2 +-
drivers/net/e2100.c |2 +-
drivers/net/eepro.c |2 +-
drivers/net/hp.c|2 +-
kernel/irq/manage.c |1 +
5 files changed, 5 insertions(+), 4 deletions(-)
diff -r 0
The problem with introducing IFF_GSO_HDR is that it needs to set dev->features
(to enable GSO, checksumming, etc), which is supposed to be done before
register_netdevice(), ie. as part of TUNSETIFF.
Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand,
so there's no good wa
.
Questions:
1) Should we rename/move virtio_net_hdr to something more generic?
2) Is this the right way to build a paged skb from user pages?
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/net/tun.c | 250 +++--
include/linux/if
On Wednesday 16 January 2008 11:06:21 Herbert Xu wrote:
> Rusty Russell <[EMAIL PROTECTED]> wrote:
> > It's far easier to deal with GSO if we don't have to parse the packet
> > to figure out the header length. Add the field to the virtio_net_hdr
> > struct (
On Tuesday 15 January 2008 22:14:22 David Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> Date: Tue, 15 Jan 2008 21:41:55 +1100
>
> > Implement skb_partial_csum_set, for setting partial csums on untrusted
> > packets.
> >
> > Use it in virtio_ne
Do we need more checking for invalid GSO fields?
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/net/tun.c| 213 +--
include/linux/if_tun.h |2
3 files changed, 189 insertions(+), 28 deletions(-)
diff -r 1057851c060f
Implement skb_partial_csum_set, for setting partial csums on untrusted packets.
Use it in virtio_net (replacing buggy version there), it's also going
to be used by TAP for partial csum support.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/net/virtio_n
It's far easier to deal with GSO if we don't have to parse the packet
to figure out the header length. Add the field to the virtio_net_hdr
struct (and fix the spaces that somehow crept in there).
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/net/virti
On Friday 11 January 2008 02:51:58 Christian Borntraeger wrote:
> What about the following patch:
Looks correct and in fact pretty orthodox.
I've folded this in, thanks!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message t
On Tuesday 18 December 2007 16:30:08 Avi Kivity wrote:
> Rusty Russell wrote:
> > Yes, I pondered this when I wrote the code. On the one hand, it's a
> > low-probability pathological corner case, on the other, your patch
> > reduces the number of timer reprograms i
On Friday 14 December 2007 05:30:31 Christian Borntraeger wrote:
> Rusty, if you decide to apply my patch, there is one downside: The
> debugging code in virtio_ring sometimes triggers with a false positive:
>
> try_fill_recv calls vring_kick. Here we do a notify to the host. This migh
> This will shorten the latency for tx.
Hi Dor!
Yes, I pondered this when I wrote the code. On the one hand, it's a
low-probability pathological corner case, on the other, your patch reduces
the number of timer reprograms in the normal case.
So I've applied it, thanks!
R
some strange races on our test system. (But
> block and net is now working on s390 and can cope with medium load. )
Obviously SMP is not something I tested under lguest, so can believe there are
nasty lurking bugs. Hope they're not too deep...
Thanks!
Rusty.
--
To unsubscribe from this list:
On Tuesday 11 December 2007 22:38:53 Christian Borntraeger wrote:
> Hello Rusty,
>
> this is a small fix for virtio_net.
> virtnet_probe already calls alloc_etherdev, which calls ether_setup.
> There is no need to do that again.
>
> Signed-off-by: Christian Borntraeger <[
/warnx/err/errx.
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
right way, and since we're not supposed to care about
out-of-tree modules...
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
;.
Currently your criterion seems to be "does the maintainer hate external
modules?" which I don't think will be what you want...
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 27 November 2007 16:35:42 Tom Tucker wrote:
> On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
> Explicitly documenting what comprises the kernel API (external,
> supported) and what comprises the kernel implementation (internal, not
> supported).
But the former is
be used by external modules at
their own risk.
> What's the real downside?
No. That's the wrong question. What's the real upside?
Let's not put code in the core because "it doesn't seem to hurt".
I'm sure you think there's a real problem, but I&
of namespaces? Is it worth the halfway point of
export-to-module?
What problem will it solve?
> I thought this was
> already covered repeatedly in the thread and indeed in Andi's code so
> there was no need to repeat it...
No, we've seen the solution and various people applyi
ng like
>
> MODULE_NAMESPACE_IMPORT(namespace);
Except C doesn't have namespaces and this mechanism doesn't create them. So
this is just complete and utter makework; as I said before, noone's going to
confuse all those udp_* functions if they're not in the udp namespac
t; modules, but I disagree with your first statement: there clearly is a
> large class of symbols that are used by multiple modules but which are
> not generically useful -- they are only useful by a certain small class
> of modules.
If it is so clear, you should be able to easily provide
On Saturday 24 November 2007 23:39:43 Andi Kleen wrote:
> On Sat, Nov 24, 2007 at 03:53:34PM +1100, Rusty Russell wrote:
> > So, you're saying that there's a problem with in-tree modules using
> > symbols they shouldn't? Can you give an example?
[ Note: no res
27;s hard to argue against an
out-of-tree module using the symbol, unless you're arguing against *all*
out-of-tree modules.
Sorry,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 23 November 2007 12:36:22 Andi Kleen wrote:
> On Friday 23 November 2007 01:25, Rusty Russell wrote:
> > That's my point. If there's a whole class of modules which can use a
> > symbol, why are we ruling out external modules?
>
> The point is to get cleane
On Thursday 22 November 2007 22:05:45 Christoph Hellwig wrote:
> On Thu, Nov 22, 2007 at 02:56:22PM +1100, Rusty Russell wrote:
> > This is an interesting idea, thanks for the code! My only question
> > is whether we can get most of this benefit by dropping the indirection of
On Thursday 22 November 2007 22:46:23 Andi Kleen wrote:
> On Thursday 22 November 2007 04:56, Rusty Russell wrote:
> > This is an interesting idea, thanks for the code! My only question
> > is whether we can get most of this benefit by dropping the indirection of
> >
(sym, modname)"? It
doesn't work so well for exporting to a group of modules, but that seems
a reasonable line to draw anyway.
Cheers,
Rusty.
PS. Probably better to use the standard warnx and errx in modpost, too.
-
To unsubscribe from this list: send the line "unsubscribe netdev&
skb is only NULL the first time around: it's more correct to test for
being under-budget.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 2a94425ac7d5 drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c Thu Nov 15 13:47:28 2007 +1100
+++ b/drivers/net/virtio_net.c Thu N
This fixes a potential dangling xmit problem.
We also suppress refill interrupts until we need them.
(Anthony and I have been working on performance recently, so this
is a WIP).
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 586fb6ff29dd drivers/net/virtio_net.c
--- a/drive
ainers" somewhere in the help text
(I'm assuming that's what it's for?).
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 5f800a6..cb581eb 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -136,1
d also be nice to mention "containers" somewhere in the
help text (I'm assuming that's what it's for?).
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 5f800a6..033a847 100644
--- a/drivers/net/Kconfig
++
On Wednesday 31 October 2007 14:40:02 David Miller wrote:
> I just checked the following bug fix into net-2.6
>
> Rusty, have a quick look at virtio_net wrt. the changes I
> made to skb_to_sgvec()'s behavior. I think I might have
> even fixed something :-)
Grr, the scatterlis
skbs (Christian Borntraeger)
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Cc: Christian Borntraeger <[EMAIL PROTECTED]>
Cc: Herbert Xu <[EMAIL PROTECTED]>
Cc: netdev@vger.kernel.org
---
drivers/net/Kconfig|6
drivers/net/Makefile |2
drivers/ne
On Tue, 2007-07-24 at 21:29 -0700, David Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> 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_TO
if (rx_pending() || !netif_rx_complete(netdev, napi))
disable_interrupts();
I'm going to go absorb some more caffeine before you reply 8)
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ould use this (ie. virt_net.c probably wants to do it even though
virtio implementation may not have this issue).
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Feedback welcome, as always!
(There's been talk of a virtualization git tree, in which case there'll
be a decent home for these patches soon).
Cheers,
Rusty.
==
Add feature and GSO support to virtio net driver.
If you don't do GSO, you can simply ignore the first sg element of
it's
worth the few-byte savings per queue.
> Any objections?
On the contrary, this looks good.
Thanks!
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
if (unlikely(ring_has_new_packet(dev)))
schedule_work(&foo->rescheduler);
return used;
}
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2007-07-22 at 00:18 -0700, David Miller wrote:
> Rusty, how does it look otherwise?
I like it. For a start, the simplification of the NAPI api was long
overdue, and the damage done by separating the napi_struct is really
minimal. Overall the tg3 driver just looks a little nicer now,
cks to hide the dev ptr before driver_private, but it's still
implementable).
Perhaps we should do this anyway: it's another "every driver wants it"
kind of deal AFAICT...
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 2007-07-21 at 11:54 -0700, David Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> Date: Sat, 21 Jul 2007 18:00:11 +1000
>
> > No, I was just thinking that drivers will put the napi_struct in their
> > driver-specific struct (eg. struct e1000_adapter
On Sat, 2007-07-21 at 00:42 -0700, David Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> Date: Sat, 21 Jul 2007 17:14:31 +1000
>
> > This looks good! It might be nice though to go further and remove the
> > internal napi_struct. It's kind of a wa
re going to have their own array (or whatever).
But I can do that as a separate patch if you think it's a decent idea.
The name "NAPI" is also a wart, but I guess it's everywhere now so one
more place isn't making things worse...
Cheers,
Rusty.
-
To unsubscribe from this
> >
> > There is now a net_device_stats element inside net_device on
> > 2.6.21 or later.
> >
>
> Ah, OK. Should I just do a s/stats/netdev->stats/? Is there a generic
> get_stats routine as well?
The default function points to the internal stats...
Cheers
provides point-to-point
> connections between different domains; i always thought that they all
> provided a point-to-point to the dom0 equivalent and let the dom0 worry
> about how things get from domainX to domainY.
Yeah, but that has obvious limitations as people care more about
inter-guest
>len.
OK, you can stop hitting me now...
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
sors have a sensible maximum on the number of guests they
could talk to, so I'm not too unhappy with a static number of queues.
But the dstmac -> queue mapping changes in hypervisor-specific ways, so
it really needs to be managed by the driver...
Hope that adds something,
Rusty.
-
To unsu
On Wed, 2007-05-09 at 22:00 +1000, Herbert Xu wrote:
> Hi Rusty:
>
> On Wed, May 09, 2007 at 09:55:25PM +1000, Rusty Russell wrote:
> >
> > NO_CSUM because it really doesn't need a checksum. The
> > LGUEST_NET_F_NOCSUM is only set for local inter-guest networ
nce the default Ethernet one limits
> the MTU to 1500.
Indeed, that would be a new feature, and is certainly a consideration
for more efficient inter-guest networking. However, I consider that
somewhat cheating: it's nice to know that 1500 doesn't suck too hard.
Remember, "Fea
On Mon, 2007-05-07 at 23:30 -0700, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > Looks good, you can slightly improve it to be the model use of new
> > module_param types by calling your functions param_set_rx_mode and
> > param_get_rx_mode, then simply using "mod
= 0)
> + *rxmp = RX_FLIP;
> + else
> + ret = -EINVAL;
> +
> + return ret;
> +}
> +
> +static int get_rx_mode(char *buffer, struct kernel_param *kp)
> +{
> + enum rx_mode *rxmp = kp->arg;
> +
> + return sprintf(buffe
_param() by say... 2012?
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2007-05-02 at 13:51 +1000, Herbert Xu wrote:
> On Wed, May 02, 2007 at 01:37:13PM +1000, Rusty Russell wrote:
> >
> > > +static int xennet_change_mtu(struct net_device *dev, int mtu)
> > > +{
> > > + int max = xennet_can_sg(dev) ? 65535 - ETH_HLEN : ETH
ld be great near that union declaration. Not
here where it's a long way from the code which uses that fact.
> +static int xennet_sysfs_addif(struct net_device *netdev)
> +{
> + int i;
> + int error = 0;
Again with the unused error initialization (plus, elsewhere it's "err").
> +static void xennet_sysfs_delif(struct net_device *netdev)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(xennet_attrs); i++) {
> + device_remove_file(&netdev->dev, &xennet_attrs[i]);
> + }
> +}
Gratuitous braces around single line.
> + printk(KERN_INFO "Initialising virtual ethernet driver.\n");
Some mention of Xen in this printk would be good, since we're already
have multiple virtual ethernet drivers.
Phew, that's the end.
Cheers!
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2007-04-11 at 22:23 +1000, Herbert Xu wrote:
> On Wed, Apr 11, 2007 at 10:15:51PM +1000, Rusty Russell wrote:
> >
> > Actually, I did this precisely because I really didn't want to start
> > exposing bogus stats in /proc/net/dev. An audit might clarify if t
ight: skb_free latency on xmit (at least for this
e1000) is far too large for anything but an async solution.
Will ponder further.
Thanks!
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2007-04-11 at 17:28 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > On Wed, 2007-04-11 at 07:26 +0300, Avi Kivity wrote:
> >
> >> Nope. Being async is critical for copyless networking:
> >>
> With async operations, the saga continues like this:
Maybe it will turn
> out not to be as difficult as I predicted just a few lines above.
Indeed, I don't think we're asking for a revolution a-la VJ-style
channels. But I'm still itching to get back to that, and this might yet
provide an excuse 8)
Cheers,
Rusty.
-
To unsubscri
o start
exposing bogus stats in /proc/net/dev. An audit might clarify if this
is an actual issue.
> So we can simply get rid of this flag.
>
> This also fixes a potential crash in those get_stats callers that
> don't check for a NULL return value (e.g., /proc/net/dev).
Hmm, I t
x27;s not argue over that, it's irrelevant. Hopefully we can do
that over a beer or equivalent sometime.
I think the first step is to see how much worse a decent userspace net
driver is compared with the current in-kernel one.
Rusty.
-
To unsubscribe from this list: send the line "unsu
On Mon, 2007-04-09 at 10:10 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > I'm a little puzzled by your response. Hmm...
> >
> > lguest's userspace network frontend does exactly as many copies as
> > Ingo's in-host-kernel code. One from the
On Sun, 2007-04-08 at 08:36 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > Hi Avi,
> >
> > I don't think you've thought about this very hard. The receive copy is
> > completely independent with whether the packet is going to the guest via
> &g
nly interested in stealing^H^H^Hsharing KVM devices.
The subject is now deeply misleading 8(
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2007-04-05 at 10:17 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > You didn't quote Anthony's point about "it's more about there not being
> > good enough userspace interfaces to do network IO."
> >
> > It's easier to write a ke
g to do until we can show that an efficient
packet-level userspace interface isn't possible. I don't think that's
been done, and it would be interesting to try.
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
un.dev_addr in sync.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r fd8c40f4f533 drivers/net/tun.c
--- a/drivers/net/tun.c Fri Mar 30 17:02:19 2007 +1000
+++ b/drivers/net/tun.c Sat Mar 31 10:30:47 2007 +1000
@@ -507,9 +507,7 @@ static int tun_set_iff(struct file *file
gh-speed drivers, otherwise we should split the tx & rx
parts of the structure.
64 bit introduces potential compatibility problems (exporting via proc).
And per-cpu feels like overkill to me.
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
Hi all,
Does something like this make sense for future drivers?
Cheers,
Rusty.
===
Network drivers which keep stats allocate their own stats structure
then write a get_stats() function to return them. It would be nice if
this were done by default.
1) Add a new "stats" field
On Tue, 2007-03-20 at 09:58 -0600, Eric W. Biederman wrote:
> Looking at the above code snippet. I guess it is about time to
> merge our per_cpu and pda variables...
Indeed, thanks for the prod. Now 2.6.21-rc4-mm1 is out, I'll resend the
patches.
Cheers,
Rusty.
-
To unsubscrib
On Mon, 2007-03-19 at 18:00 -0800, Zachary Amsden wrote:
> Rusty Russell wrote:
> > *This* was the reason that the current hand-coded calls only clobber %
> > eax. It was a compromise between native (no clobbers) and others (might
> > need a reg).
>
> I still don&#x
orted SMP).
The current 6 paravirt ops which are patched cover the vast majority of
calls (until the Xen patches, then we need ~4 more?). Jeremy chose to
expand patching to cover *all* paravirt ops, rather than just the new
hot ones, and that's where we tipped over the ugliness threshold.
Ch
nline. For lguest this covers popf and pushf, but not cli
and sti (10 bytes): they'd have to be calls.
As for clobber info, it turns out that almost all of the calls can
clobber %eax, which is probably enough. We just need to mark the
handful of asm ones where this isn't true.
Thou
all just doing that.
> What are the netdev requirements?
Reading Ben LaHaise's (very cool!) patch, it's not clear that using
reloc postprocessing is going to be clearer than open-coding it as he
has done.
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2006-07-31 at 21:47 -0700, David Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> Date: Fri, 28 Jul 2006 15:54:04 +1000
>
> > (1) I am imagining some Grand Unified Flow Cache (Olsson trie?) that
> > holds (some subset of?) flows. A successful lookup i
On Wed, 2006-07-26 at 23:00 -0700, David Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> Date: Thu, 27 Jul 2006 15:46:12 +1000
>
> > Yes, my first thought back in January was how netfilter would interact
> > with this in a sane way. One answer is "don&#
On Thu, 2006-07-27 at 20:33 +0400, Alexey Kuznetsov wrote:
> Hello!
>
> On Thu, Jul 27, 2006 at 03:46:12PM +1000, Rusty Russell wrote:
> > Of course, it means rewriting all the userspace tools, documentation,
> > and creating a complete new infrastructure for connection trac
ead:
SRCIP/DSTIP/PROTO/SPT/DPT/IN/OUT (where IN and OUT are boolean values
indicating whether the src/dest is local).
Of course, it means rewriting all the userspace tools, documentation,
and creating a complete new infrastructure for connection tracking and
NAT, but if that's what's requir
y skip first level of lookup. This
should allow us to identify which flows are simple enough to be directly
accelerated (whether by channels or something else): no bonding, raw
sockets, non-trivial netfilter rules, connection tracking changes, etc.
Thoughts?
Rusty.
--
Help! Save Australia from the
global generic system packet memory
> limits.
>
> These two things can tie in together.
Hi Dave,
We kept a simple "used" bitmap, but to avoid the consumer touching it,
also put a "I am masquerading as an SKB" bit in the trailer, like so:
diff -urpN --exclude TAGS
On Fri, 2006-04-28 at 15:40 -0700, David S. Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> Date: Sat, 29 Apr 2006 08:17:01 +1000
> > However, in future, if intelligent cards exist, having an API which lets
> > them do zero-copy and not overly penalize less
On Fri, 2006-04-28 at 15:38 -0700, David S. Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> Date: Sat, 29 Apr 2006 08:04:04 +1000
>
> > You're still thinking you can bypass classifiers for established
> > sockets, but I really don't think you can.
is probably the best approach for the initial efforts.
Absolutely.
Cheers!
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2006-04-28 at 12:21 -0700, David S. Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> Date: Fri, 28 Apr 2006 18:24:08 +1000
>
> > Note that the problem space AFAICT includes strange advanced routing
> > setups, ingress qos and possibly others, not just
7;s not clear how one should sanely mix this with sendfile
etc. Maybe you don't, and only use this for RDMA, etc.
Cheers!
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ilter hook processing won't work for intelligent NICs that
write straight to mmapped buffers, but we could make that CAP_NET_RAW.
We *used* to have an nf_cache mechanism to determine exactly when the
netfilter hooks cared about a packet, but it was never used and was hard
to reconcile wit
98 matches
Mail list logo
