Linhaifeng haifeng@huawei.com writes:
On 2015/6/4 9:13, Rusty Russell wrote:
Linhaifeng haifeng@huawei.com 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
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 wrong.
I'm not sure
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 [EMAIL PROTECTED
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
include/linux
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, 238 insertions
)
printf((UNKNOWN %#x), features);
printf(\n);
return 0;
}
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
---
drivers/net/tun.c |9 +
include/linux/if_tun.h |3 +++
2 files changed, 12 insertions(+)
diff -r c0e7a8b99325 drivers/net/tun.c
--- a/drivers/net/tun.c Wed
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 code. The BUG catches future changes
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 virtio_net_hdr
struct (and fix the spaces
.
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_tun.h |2
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
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 0b7e4fbb6238
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 changed, 3
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_net.c | 11
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/virtio_net.c |4 +++-
include
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 drivers/net
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_net (replacing buggy version there), it's also going
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 (and fix the spaces that somehow crept
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 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_xmit sets
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 virtnet_open(struct net_devic
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 in the normal case.
One thing
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.
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 [EMAIL PROTECTED]
Acked-by: Rusty
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 this
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 symbol
But
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 generically
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
namespace.
I
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 response to this ]
If people aren't
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 your
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 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 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
namespaces and have something
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
namespaces and have
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 cleaner interfaces.
But this doesn't change
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 only
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/drivers/net
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 Nov 15 23:10
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
+++ b/drivers/net/Kconfig
@@ -135,11 +135,12 @@ config TUN
-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,10 +136,11 @@ config TUN
If you don't know what to use this for, you don't need it.
config VETH
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 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
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 insertions(+), 12 deletions
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
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 in
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_TODO bit (atomically instead
of setting
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 using
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 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 drivers to
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 wart for multi-queue drivers which
are going
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 *adapter =
container_of(container_of
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 at least on
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_device on
2.6.21 or
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 which is a
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 else.
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 hitting
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 NO_CSUM
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 networking. If
some guest were to route
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 module_param(rx_mode, rx_mode,
0400
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 backend into
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() by
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-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_DATA_LEN;
This seems odd to me: just because
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 to
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 (which
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: the host-side
driver allocates an skb, get_page
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 Guest, one to the Guest.
kvm pvnet is suboptimal
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
a kernel driver or via userspace, so not relevant
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.
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 tunneled
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
tun-flags = flags
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/appldata/appldata_net_sum.c
--- a/arch/s390/appldata/appldata_net_sum.c
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
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 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 smaller
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't think this was a good trade.
...
Xen
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 and crap
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-read-only
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 tracking and
NAT, but if that's
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't: once someone registers
on any hook we
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 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 some
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
keep
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 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 netfilter. But
perhaps the same
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. I think the simplest
solution
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 intelligent cards makes
sense.
I
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 rules that
89 matches
Mail list logo
