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
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_INTERRUPT when no callbacks?
> I think we should set avail->flags to VRING_AVAIL_F_NO_INTERRUPT even if no
> callbacks.
Hi Linhaifeng,
Not su
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 to [EMAIL PROTECTED]
More
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
process the input queue once
on open.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 1dd61213039c drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c Tue Dec 18 17:34:18 2007 +1100
+++ b/drivers/net/virtio_net.c Tue Dec 18 17:47:39 2007 +1100
@@ -326,6 +326,13 @@ static int
On Wednesday 12 December 2007 23:54:00 Dor Laor wrote:
> commit 763769621d271d92204ed27552d75448587c1ac0
> Author: Dor Laor <[EMAIL PROTECTED]>
> Date: Wed Dec 12 14:52:00 2007 +0200
>
> [virtio-net][PATCH] Don't arm tx hrtimer with a constant 50us each
> transmit
>
> The current start_xm
On Wednesday 12 December 2007 00:16:12 Christian Borntraeger wrote:
> That would also work. We already have VRING_AVAIL_F_NO_INTERRUPT in
> virtio_ring.c - maybe we can use that. Its hidden in callback and
> restart handling, what about adding an explicit startup?
Yes, I debated whether to make th
EMAIL PROTECTED]>
Acked-by: Rusty Russell <[EMAIL PROTECTED]>
Can you send straight to akpm or davem? I'm supposed to be on vacation at the
moment (and not doing a very good job :)
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
On Tuesday 11 December 2007 05:50:08 Sam Ravnborg wrote:
> On Thu, Nov 22, 2007 at 03:43:08AM +0100, Andi Kleen wrote:
> > This way gcc can warn for wrong format strings
>
> This loks good. Can I get i s-o-b then I will apply it.
Even better, switch the code to the standard warn/warnx/err/errx.
C
On Friday 30 November 2007 03:53:34 Arjan van de Ven wrote:
> On Mon, 26 Nov 2007 10:25:33 -0800
>
> > Agreed. On first glance, I was intrigued but:
> >
> > 1) Why is everyone so concerned that export symbol space is large?
> > - does it cost cpu or running memory?
>
> yes. about 120 bytes per
On Tuesday 27 November 2007 21:50:16 Andi Kleen wrote:
> Goals are:
> - Limit the interfaces available for out of tree modules to reasonably
> stable ones that are already used by a larger set of drivers.
Not the goals. I haven't seen the *problem* yet.
> - Limit size of exported API to make sta
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
On Monday 26 November 2007 17:15:44 Roland Dreier wrote:
> > 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
On Monday 26 November 2007 16:58:08 Roland Dreier wrote:
> > > I agree that we shouldn't make things too hard for out-of-tree
> > > 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 generi
On Monday 26 November 2007 07:27:03 Roland Dreier wrote:
> > This patch allows to export symbols only for specific modules by
> > introducing symbol name spaces. A module name space has a white
> > list of modules that are allowed to import symbols for it; all others
> > can't use the symbols.
On Monday 26 November 2007 07:29:39 Roland Dreier wrote:
> > Yes, and if a symbol is already used by multiple modules, it's
> > generically useful. And if so, why restrict it to in-tree modules?
>
> I agree that we shouldn't make things too hard for out-of-tree
> modules, but I disagree with you
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
On Saturday 24 November 2007 06:53:30 Andi Kleen wrote:
> This serves as a documentation
> on what is considered internal. And if some obscure module (in or
> out of tree) wants to use an internal interface they first have
> to send the module maintainer a patch and get some review this way.
So,
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
> >
On Thursday 22 November 2007 13:43:06 Andi Kleen wrote:
> There seems to be rough consensus that the kernel currently has too many
> exported symbols. A lot of these exports are generally usable utility
> functions or important driver interfaces; but another large part are
> functions intended by o
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 scatterlist changes are really
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
On Tue, 2007-07-24 at 18:47 -0700, David Miller wrote:
> One thing that's peculiar is that when netif_rx_schedule_prep()
> fails, we don't disable interrupts but we also don't clear the
> condition that is causing the interrupt to occur.
I think we're ok, but this stuff is tricky.
In the driver i
On Tue, 2007-07-24 at 17:45 -0700, David Miller wrote:
> I'm now going to go over the other resched cases and make sure
> things can be similarly handled in those drivers as well.
> To be honest I'm quite confident this will be the case.
If I understand correctly, you're looking at a general model
every outgoing packet, and tack a dummy one on every incoming.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/net/virtio_net.c | 130
include/linux/virtio_net.h | 25 +++-
2 files changed, 143 insert
On Mon, 2007-07-23 at 22:47 -0700, David Miller wrote:
> I don't think it's wise to implement this over and over again in each
> driver, since we already know at least a handfull of drivers will use
> this.
Yep. Alternative is a napi_struct_with_restart, but I don't think it's
worth the few-byte
On Mon, 2007-07-23 at 21:07 -0700, David Miller wrote:
> Another area of consternation are drivers that were using
> netif_rx_reschedule(), as that interface was removed because it
> doesn't fit well with the caller managing the dev->quota et al. I
> left race conditions in the drivers that were u
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, and
On Sat, 2007-07-21 at 18:59 -0700, David Miller wrote:
> But note that you'd be adding a pointer deref, the current sequence:
>
> napi_struct --> netdev --> driver_private
>
> involves all pointer arithmetic and no derefs, whereas:
>
> napi_struct --> driver_private --> netdev
>
> will involve
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
On Fri, 2007-07-20 at 22:31 -0700, David Miller wrote:
> Stephen asked me if I could resurrect the last version of
> his napi_poll patch that I posted a long time ago, I finally
> got to that tonight.
>
> Basically, this disconnects the ->poll() object from the net
> device. This will allow drive
On Tue, 2007-07-17 at 07:28 -0700, Jeremy Fitzhardinge wrote:
> Stephen Hemminger wrote:
> >> +struct netfront_info {
> >> + struct list_head list;
> >> + struct net_device *netdev;
> >> +
> >> + struct net_device_stats stats;
> >>
> >
> > There is now a net_device_stats element inside net_
On Fri, 2007-07-06 at 10:39 -0400, jamal wrote:
> The first thing that crossed my mind was "if you want to select a
> destination port based on a destination MAC you are talking about a
> switch/bridge". You bring up the issue of "a huge number of virtual NICs
> if you wanted arbitrary guests" whic
On Thu, 2007-07-05 at 17:15 -0700, David Miller wrote:
> Also even with the scatterlist idea, we'd still need to do two
> map calls, one for skb->data and one for the page vector.
We could make skb->shinfo(skb)->frags[0] the first segment and deprecate
skb->data and skb->len.
OK, you can stop hit
On Tue, 2007-07-03 at 22:20 -0400, jamal wrote:
> On Tue, 2007-03-07 at 14:24 -0700, David Miller wrote:
> [.. some useful stuff here deleted ..]
>
> > That's why you have to copy into a purpose-built set of memory
> > that is composed of pages that _ONLY_ contain TX packet buffers
> > and nothing
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
On Wed, 2007-05-09 at 20:12 +1000, Herbert Xu wrote:
> [EMAIL PROTECTED] wrote:
> >
> > + if (desc->features & LGUEST_NET_F_NOCSUM)
> > + dev->features |= NETIF_F_NO_CSUM;
>
> Any reason why you're using NO_CSUM here instead of HW_CSUM?
> Practically there is no difference but
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
On Mon, 2007-05-07 at 14:11 -0700, Jeremy Fitzhardinge wrote:
> Christoph Hellwig wrote:
> > On Fri, May 04, 2007 at 04:21:16PM -0700, Jeremy Fitzhardinge wrote:
> >
> >> +/*
> >> + * Mutually-exclusive module options to select receive data path:
> >> + * rx_copy : Packets are copied by network
On Sat, 2007-05-05 at 10:16 +0100, Christoph Hellwig wrote:
> I wish people would have listened to me back then and made the
> description part of the modular_param statement..
Sometimes we weary of change. However, come up with a decent name and
implement it and we can deprecate module_param() b
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
On Tue, 2007-05-01 at 17:08 -0700, Jeremy Fitzhardinge wrote:
> Add the Xen virtual network device driver.
(Herbert: there's a question for you: grep for Herbert)
OK, this is a remarkably non-trivial driver. If the v0.1 of the driver
had been in the kernel, I'm sure it would have been about 1/4
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
On Thu, 2007-04-12 at 06:32 +0300, Avi Kivity wrote:
> I hadn't considered an always-blocking (or unbuffered) networking API.
> It's very counter to current APIs, but does make sense with things like
> syslets. Without syslets, I don't think it's very useful as you need
> some artificial threads
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:
On Wed, 2007-04-11 at 07:26 +0300, Avi Kivity wrote:
> Nope. Being async is critical for copyless networking:
>
> - in the transmit path, so need to stop the sender (guest) from touching
> the memory until it's on the wire. This means 100% of packets sent will
> be blocked.
Hi Avi,
You
On Wed, 2007-04-11 at 17:56 +1000, Herbert Xu wrote:
> Hi:
>
> [NET]: Get rid of NETIF_F_INTERNAL_STATS
>
> The recently added NETIF_F_INTERNAL_STATS isn't very useful. If the
> device driver needs to set it then it can always override get_stats
> instead. All existing drivers that have stats (
On Mon, 2007-04-09 at 16:38 +0300, Avi Kivity wrote:
> Moreover, some things just don't lend themselves to a userspace
> abstraction. If we want to expose tso (tcp segmentation offload), we
> can easily do so with a kernel driver since the kernel interfaces are
> all tso aware. Tacking on tso
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
On Thu, 2007-04-05 at 13:36 +0200, Ingo Molnar wrote:
> prototyping new kernel APIs to implement user-space network drivers, on
> a crufty codebase is not something that should be done lightly.
I think you overestimate my radicalism. I was considering readv() and
writev() on the tap device.
Qem
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
On Wed, 2007-04-04 at 23:21 +0200, Ingo Molnar wrote:
> * Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
> > But why is it a good thing to do PV drivers in the kernel? You lose
> > flexibility and functionality to gain performance. [...]
>
> in Linux a kernel-space network driver can still be tun
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
On Wed, 2007-03-28 at 08:52 -0700, Stephen Hemminger wrote:
> It would make sense to do it per-cpu and 64 bit for the non-error counters.
Well, I looked at the e1000, it doesn't update on every packet anyway,
but seems to d/l from the card occasionally. I assume this is the
method for high-speed
ould not break backwards compatibility with older drivers, yet
allow modern drivers to shed some boilerplate code.
Lightly tested: works for a modified lguest network driver.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
0 files changed
diff -r 1ccab0a087b7 arch/s390/app
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 unsubscribe from this list
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
On Mon, 2007-03-19 at 11:38 -0700, Linus Torvalds wrote:
>
> On Mon, 19 Mar 2007, Eric W. Biederman wrote:
> >
> > True. You can use all of the call clobbered registers.
>
> Quite often, the biggest single win of inlining is not so much the code
> size (although if done right, that will be sma
On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote:
> > The idea is _NOT_ that you go look for references to the paravirt_ops
> > members structure, that would be stupid and you wouldn't be able to
> > use the most efficient addressing mode on a given cpu, you'd be
> > patching up indirect calls a
On Fri, 2007-03-16 at 13:38 -0700, Jeremy Fitzhardinge wrote:
> David Miller wrote:
> > Perhaps the problem can be dealt with using ELF relocations.
> >
> > There is another case, discussed yesterday on netdev, where run-time
> > resolution of ELF relocations would be useful (for
> > very-very-very
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
On Wed, 2006-07-26 at 22:17 -0700, David Miller wrote:
> I read this as "we will be able to get around the problems" but
> no specific answer as to "how". I am an optimist too but I want
> to start seeing concrete discussion about the way in which the
> problems will be dealt with.
>
> Alexey has
On Wed, 2006-07-19 at 03:01 +0400, Alexey Kuznetsov wrote:
> Hello!
>
> Can I ask couple of questions? Just as a person who looked at VJ's
> slides once and was confused. And startled, when found that it is not
> considered as another joke of genuis. :-)
Hi Alexey!
> About locks:
>
> > is
On Thu, 2006-05-04 at 16:22 -0700, David S. Miller wrote:
> From: Kelly Daly <[EMAIL PROTECTED]>
> Date: Thu, 4 May 2006 12:59:23 +1000
>
> > We DID write an infrastructure to resolve this issue, although it is more
> > complex than the dynamic descriptor scheme for userspace. And we want to
>
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.
On Fri, 2006-04-28 at 10:55 -0700, Caitlin Bestler wrote:
> vj_netchannels represent a strategy of minimizing
> registration/pinning costs even if it means paying for an extra copy.
> Because the extra copy is closely tied to the activation of the data
> sink consumer the cost of that extra copy is
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
On Thu, 2006-04-27 at 14:12 -0700, Caitlin Bestler wrote:
> So the real issue is when there is an intelligent device that
> uses hardware packet classification to place the packet in
> the correct ring. We don't want to bypass packet filtering,
> but it would be terribly wasteful to reclassify the
On Wed, 2006-04-26 at 12:30 -0700, Caitlin Bestler wrote:
> David S. Miller wrote:
>
> >
> > I personally think allowing sockets to trump firewall rules
> > is an acceptable relaxation of the rules in order to simplify
> > the implementation.
>
> I agree. I have never seen a set of netfilter ru
97 matches
Mail list logo
