* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 19:16 UTC (permalink / raw)
To: johnpol; +Cc: shemminger, caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428175538.GA13898@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Fri, 28 Apr 2006 21:55:39 +0400
> On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> > Second, introducing
> > kevents, seems unnecessary and hasn't been accepted in the mainline.
>
> kevent was never sent to lkml@ although it showed over 40% win over epoll for
> test web server. Sending it to lkml@ is just jumping into ... not into
> technical world, so I posted it first here, but without much attention
> though.
Frankly I found kevents to be a very strong idea.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 19:21 UTC (permalink / raw)
To: rusty; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <1146212660.8029.38.camel@localhost.localdomain>
From: Rusty Russell <rusty@rustcorp.com.au>
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 solutions apply, so I'll concentrate on nf.
Yes, this hasn't been mentioned explicitly yet.
The big problem is that we don't want the classifier to become
overly complex.
One scheme I'm thinking about right now is an ordered lookup
that looks like:
1) Check for established sockets, they trump everything else.
2) Check for classifier rules, ie. netfilter and packet scheduler
stuff
3) Check for listening sockets
4) default channel
#2 is still an unsolved problem, we don't want this big complex
classifier to be required in the hardware implementations.
However, using just IP addresses and ports does not map well to
what netfilter and co. want.
> Ah, this is a different problem. Our idea was to have a syscall which
> would check & sanitize the buffers for output. To do this, you need the
> ability to chain buffers (a simple next entry in the header, for us).
>
> Sanitization would copy the header into a global buffer (ie. not one
> reachable by userspace), check the flowid, and chain on the rest of the
> user buffer. After it had sanitized the buffers, it would activate the
> NIC, which would only send out buffers which started with a kernel
> buffer.
>
> Of course, the first step (CAP_NET_RAW-only) wouldn't need this. And,
> if the "sanitize_and_send" syscall were PF_VJCHAN's write(), then the
> contents of the write() could actually be the header: userspace would
> never deal with chained buffers.
I am not sure any of this is anything more than overhead.
If we just pop the buffers directly into the user mmap()'d ring
buffer, headers and all, and give an offset+length pair so the
user knows where the data starts and how much data is there, it
should all just work out. Where to put the offset+length is
just a detail.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Stephen Hemminger @ 2006-04-28 19:49 UTC (permalink / raw)
To: David S. Miller; +Cc: johnpol, caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428.121636.54294183.davem@davemloft.net>
On Fri, 28 Apr 2006 12:16:36 -0700 (PDT)
"David S. Miller" <davem@davemloft.net> wrote:
> From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Date: Fri, 28 Apr 2006 21:55:39 +0400
>
> > On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> > > Second, introducing
> > > kevents, seems unnecessary and hasn't been accepted in the mainline.
> >
> > kevent was never sent to lkml@ although it showed over 40% win over epoll for
> > test web server. Sending it to lkml@ is just jumping into ... not into
> > technical world, so I posted it first here, but without much attention
> > though.
>
> Frankly I found kevents to be a very strong idea.
But there is this huge semantic overload of kevent, poll, epoll, aio,
regular sendmsg/recv, posix aio, etc.
Perhaps a clean break with the socket interface is needed. Otherwise, there
are nasty complications with applications that mix old socket calls and new interface
on the same connection.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov @ 2006-04-28 19:52 UTC (permalink / raw)
To: David S. Miller; +Cc: shemminger, caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428.121636.54294183.davem@davemloft.net>
On Fri, Apr 28, 2006 at 12:16:36PM -0700, David S. Miller (davem@davemloft.net) wrote:
> From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Date: Fri, 28 Apr 2006 21:55:39 +0400
>
> > On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> > > Second, introducing
> > > kevents, seems unnecessary and hasn't been accepted in the mainline.
> >
> > kevent was never sent to lkml@ although it showed over 40% win over epoll for
> > test web server. Sending it to lkml@ is just jumping into ... not into
> > technical world, so I posted it first here, but without much attention
> > though.
>
> Frankly I found kevents to be a very strong idea.
Glad to hear this.
I probably should resend patches netdev@ and (mar my karma) send it to
lkml@...?
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
From: Santiago Leon @ 2006-04-28 19:51 UTC (permalink / raw)
To: michael; +Cc: jgarzik, anton, linuxppc64-dev, netdev
In-Reply-To: <1146047837.10735.29.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 314 bytes --]
Michael Ellerman wrote:
>>Looks like this hit the floor. Any chance of getting it into to 2.6.17
>>Jeff? AFAICT it should still apply cleanly.
>
> /me knocks politely
Actually, it doesn't apply cleanly anymore. Here's a patch that does.
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
[-- Attachment #2: ibmveth_harden_init.patch --]
[-- Type: text/plain, Size: 2193 bytes --]
From: Michael Ellerman <michael@ellerman.id.au>
After a kexec the ibmveth driver will fail when trying to register with the Hypervisor because the previous kernel has not unregistered.
So if the registration fails, we unregister and then try again.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Santiago Leon <santil@us.ibm.com>
ibmveth.c | 31 ++++++++++++++++++++++++++-----
1 file changed, 26 insertions(+), 5 deletions(-)
Index: kexec/drivers/net/ibmveth.c
===================================================================
--- a/drivers/net/ibmveth.c 2006-04-28 13:16:22.244724056 -0500
+++ b/drivers/net/ibmveth.c 2006-04-28 13:29:49.429736784 -0500
@@ -436,6 +436,31 @@ static void ibmveth_cleanup(struct ibmve
ibmveth_free_buffer_pool(adapter, &adapter->rx_buff_pool[i]);
}
+static int ibmveth_register_logical_lan(struct ibmveth_adapter *adapter,
+ union ibmveth_buf_desc rxq_desc, u64 mac_address)
+{
+ int rc, try_again = 1;
+
+ /* After a kexec the adapter will still be open, so our attempt to
+ * open it will fail. So if we get a failure we free the adapter and
+ * try again, but only once. */
+retry:
+ rc = h_register_logical_lan(adapter->vdev->unit_address,
+ adapter->buffer_list_dma, rxq_desc.desc,
+ adapter->filter_list_dma, mac_address);
+
+ if (rc != H_SUCCESS && try_again) {
+ do {
+ rc = h_free_logical_lan(adapter->vdev->unit_address);
+ } while (H_IS_LONG_BUSY(rc) || (rc == H_BUSY));
+
+ try_again = 0;
+ goto retry;
+ }
+
+ return rc;
+}
+
static int ibmveth_open(struct net_device *netdev)
{
struct ibmveth_adapter *adapter = netdev->priv;
@@ -505,11 +530,7 @@ static int ibmveth_open(struct net_devic
ibmveth_debug_printk("receive q @ 0x%p\n", adapter->rx_queue.queue_addr);
- lpar_rc = h_register_logical_lan(adapter->vdev->unit_address,
- adapter->buffer_list_dma,
- rxq_desc.desc,
- adapter->filter_list_dma,
- mac_address);
+ lpar_rc = ibmveth_register_logical_lan(adapter, rxq_desc, mac_address);
if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk("h_register_logical_lan failed with %ld\n", lpar_rc);
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov @ 2006-04-28 19:59 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428124915.686911c1@localhost.localdomain>
On Fri, Apr 28, 2006 at 12:49:15PM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> But there is this huge semantic overload of kevent, poll, epoll, aio,
> regular sendmsg/recv, posix aio, etc.
>
> Perhaps a clean break with the socket interface is needed. Otherwise, there
> are nasty complications with applications that mix old socket calls and new interface
> on the same connection.
kevent can be used as poll without any changes to the socket code.
There are two types of network related kevents - socket events
(recv/send/accept) and network aio, which can be turned completely off
in config.
There are following events which are supported by kevent:
o usual poll/select notifications
o inode notifications (create/remove)
o timer notifications
o socket notifications (send/recv/accept)
o network aio system
o fs aio (project closed, aio_sendfile() is being developed instead)
Any of the above can be turned off by config option.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Brent Cook @ 2006-04-28 20:46 UTC (permalink / raw)
To: David S. Miller; +Cc: shemminger, caitlinb, johnpol, kelly, rusty, netdev
In-Reply-To: <20060428.121052.39249337.davem@davemloft.net>
On Friday 28 April 2006 14:10, David S. Miller wrote:
> From: Stephen Hemminger <shemminger@osdl.org>
> Date: Fri, 28 Apr 2006 10:18:33 -0700
>
> > Please just use existing AIO interface.
>
> I totally disagree, the existing AIO interface is garbage.
>
> We need new APIs to do this right, to get the ring buffer
> and the zero-copy'ness correct.
> -
Heh, like PF_RING? Just mmap a socket and read out some structures?
^ permalink raw reply
* [patch] cleanup unused macro in net/netlink/af_netlink.c
From: S P @ 2006-04-28 20:51 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 232 bytes --]
1 line removal, of unused macro.
ran 'egrep -r' from linux-2.6.16/ for Nprintk and
didn't see it anywhere else but here, in #define...
------------------------------------------------
signed off by: soyoung park<speattle@yahoo.com>
[-- Attachment #2: 1497678878-remove_unused_macro.txt --]
[-- Type: text/plain, Size: 313 bytes --]
--- linux-2.6.16/net/netlink/af_netlink.c~ Sun Mar 19 21:53:29 2006
+++ linux-2.6.16/net/netlink/af_netlink.c Fri Apr 28 13:41:52 2006
@@ -61,7 +61,6 @@
#include <net/scm.h>
#include <net/netlink.h>
-#define Nprintk(a...)
#define NLGRPSZ(x) (ALIGN(x, sizeof(unsigned long) * 8) / 8)
struct netlink_sock {
^ permalink raw reply
* [PATCH] ibmveth support for netpoll
From: Santiago Leon @ 2006-04-28 21:53 UTC (permalink / raw)
To: jgarzik, netdev
[-- Attachment #1: Type: text/plain, Size: 187 bytes --]
This patch adds NETPOLL support for the ibmveth driver. Please apply.
Signed-off-by: Santiago Leon <santil@us.ibm.com>
ibmveth.c | 11 +++++++++++
1 file changed, 11 insertions(+)
[-- Attachment #2: ibmveth_netpoll.patch --]
[-- Type: text/plain, Size: 884 bytes --]
--- a/drivers/net/ibmveth.c 2006-04-28 13:16:22.244724056 -0500
+++ b/drivers/net/ibmveth.c 2006-04-28 13:17:59.971778584 -0500
@@ -918,6 +918,14 @@ static int ibmveth_change_mtu(struct net
return 0;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void ibmveth_poll_controller(struct net_device *dev)
+{
+ ibmveth_replenish_task(dev->priv);
+ ibmveth_interrupt(dev->irq, dev, NULL);
+}
+#endif
+
static int __devinit ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
{
int rc, i;
@@ -989,6 +997,9 @@ static int __devinit ibmveth_probe(struc
netdev->ethtool_ops = &netdev_ethtool_ops;
netdev->change_mtu = ibmveth_change_mtu;
SET_NETDEV_DEV(netdev, &dev->dev);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ netdev->poll_controller = ibmveth_poll_controller;
+#endif
netdev->features |= NETIF_F_LLTX;
spin_lock_init(&adapter->stats_lock);
^ permalink raw reply
* Re: [PATCH] ibmveth change buffer pools dynamically
From: Santiago Leon @ 2006-04-28 21:53 UTC (permalink / raw)
To: jgarzik, netdev
In-Reply-To: <1145981998.16266.5.camel@santilt>
Santiago Leon wrote:
> This patch provides a sysfs interface to change some properties of the
> ibmveth buffer pools (size of the buffers, number of buffers per pool,
> and whether a pool is active). Ethernet drivers use ethtool to provide
> this type of functionality. However, the buffers in the ibmveth driver
> can have an arbitrary size (not only regular, mini, and jumbo which are
> the only sizes that ethtool can change), and also ibmveth can have an
> arbitrary number of buffer pools
>
> Under heavy load we have seen dropped packets which obviously kills TCP
> performance. We have created several fixes that mitigate this issue,
> but we definitely need a way of changing the number of buffers for an
> adapter dynamically. Also, changing the size of the buffers allows
> users to change the MTU to something big (bigger than a jumbo frame)
> greatly improving performance on partition to partition transfers.
>
> The patch creates directories pool1...pool4 in the device directory in
> sysfs, each with files: num, size, and active (which default to the
> values in the mainline version).
>
> Comments and suggestions are welcome...
>
Jeff, if you don't have any problem with this patch, can you apply it?
Thanks,
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: David Gómez @ 2006-04-28 21:58 UTC (permalink / raw)
To: Pekka J Enberg; +Cc: David Vrabel, Francois Romieu, Linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.58.0604281458110.19801@sbz-30.cs.Helsinki.FI>
Hi Pekka,
On Apr 28 at 02:59:01, Pekka J Enberg wrote:
> Here are some suggestions for coding style cleanups:
Couple of questions,
> - Use dev_{dbg,err,info,warn} for logging
Cannot, i need a "struct device" and most of the
there's only access to a "struct net_device". Am i
missing something?
> - Use proper naming convention for things like Length and pPHYParam
What's the convention for these names?
Thanks,
--
David Gómez Jabber ID: davidge@jabber.org
^ permalink raw reply
* Re: [patch] cleanup unused macro in net/netlink/af_netlink.c
From: David S. Miller @ 2006-04-28 21:59 UTC (permalink / raw)
To: speattle; +Cc: netdev
In-Reply-To: <20060428205143.20727.qmail@web36613.mail.mud.yahoo.com>
From: S P <speattle@yahoo.com>
Date: Fri, 28 Apr 2006 13:51:43 -0700 (PDT)
> 1 line removal, of unused macro.
> ran 'egrep -r' from linux-2.6.16/ for Nprintk and
> didn't see it anywhere else but here, in #define...
>
> ------------------------------------------------
> signed off by: soyoung park<speattle@yahoo.com>
Patch applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 22:00 UTC (permalink / raw)
To: johnpol; +Cc: shemminger, caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428195930.GB21294@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Fri, 28 Apr 2006 23:59:30 +0400
> kevent can be used as poll without any changes to the socket code.
> There are two types of network related kevents - socket events
> (recv/send/accept) and network aio, which can be turned completely off
> in config.
> There are following events which are supported by kevent:
> o usual poll/select notifications
> o inode notifications (create/remove)
> o timer notifications
> o socket notifications (send/recv/accept)
> o network aio system
> o fs aio (project closed, aio_sendfile() is being developed instead)
>
> Any of the above can be turned off by config option.
Feel free to post the current version of your kevent patch
here so we can discuss something concrete.
Maybe you have even some toy example user applications that
use kevent that people can look at too? That might help
in understanding how it's supposed to be used.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Rusty Russell @ 2006-04-28 22:04 UTC (permalink / raw)
To: David S. Miller; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <20060428.122102.76435590.davem@davemloft.net>
On Fri, 2006-04-28 at 12:21 -0700, David S. Miller wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
> 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 solutions apply, so I'll concentrate on nf.
>
> Yes, this hasn't been mentioned explicitly yet.
>
> The big problem is that we don't want the classifier to become
> overly complex.
>
> One scheme I'm thinking about right now is an ordered lookup
> that looks like:
>
> 1) Check for established sockets, they trump everything else.
>
> 2) Check for classifier rules, ie. netfilter and packet scheduler
> stuff
>
> 3) Check for listening sockets
>
> 4) default channel
>
> #2 is still an unsolved problem, we don't want this big complex
> classifier to be required in the hardware implementations.
> However, using just IP addresses and ports does not map well to
> what netfilter and co. want.
You're still thinking you can bypass classifiers for established
sockets, but I really don't think you can. I think the simplest
solution is to effectively remove from (or flag) the established &
listening hashes anything which could be effected by classifiers, so
those packets get send through the default channel.
This can graduate from "all or nothing" to some more fine-grained scheme
over time. I have some early thoughts on how we could really do this
with filtering by connection tracking state; serious work, but feasible.
> > Ah, this is a different problem. Our idea was to have a syscall which
> > would check & sanitize the buffers for output. To do this, you need the
> > ability to chain buffers (a simple next entry in the header, for us).
> >
> > Sanitization would copy the header into a global buffer (ie. not one
> > reachable by userspace), check the flowid, and chain on the rest of the
> > user buffer. After it had sanitized the buffers, it would activate the
> > NIC, which would only send out buffers which started with a kernel
> > buffer.
> >
> > Of course, the first step (CAP_NET_RAW-only) wouldn't need this. And,
> > if the "sanitize_and_send" syscall were PF_VJCHAN's write(), then the
> > contents of the write() could actually be the header: userspace would
> > never deal with chained buffers.
>
> I am not sure any of this is anything more than overhead.
>
> If we just pop the buffers directly into the user mmap()'d ring
> buffer, headers and all, and give an offset+length pair so the
> user knows where the data starts and how much data is there, it
> should all just work out. Where to put the offset+length is
> just a detail.
Agreed, but I was talking about userspace *send*, in reply to Caitlin
bringing it up. A little off-topic, but I mentioned our thoughts simply
to show that it's possible to do unpriv'ed output...
(Kelly is taking a couple of well-earned days off ATM).
Cheers!
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
^ permalink raw reply
* RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Rusty Russell @ 2006-04-28 22:17 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: Evgeniy Polyakov, David S. Miller, kelly, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F143B10A@NT-SJCA-0751.brcm.ad.broadcom.com>
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 greatly reduced because
> it places the data in the cache immediately before the application
> will in fact use the received data.
Just to be clear here: I agree with Dave that without classifying
hardware, there's no point (and much pain) in going all the way to
userspace with the channel (ie. mmap). If you're going to copy anyway,
might as well do it in the socket's read() call: then the user can then
aim the copy exactly where they want, too. We'll need that TCP code in
the kernel for the foreseeable future anyway 8)
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.
Side note: my Xen I/O patches allow the implementation of exactly this
kind of virtual hardware (no coincidence 8), so intelligent cards might
not be as far away as you think...
> Also keep in mind that once the issues are resolved to allow the
> netchannel rings to be directly visible to a user-mode client that
> enhanced/specialized interfaces can easily be added in user-mode
> libraries. So focusing on supporting existing conventional interfaces
> is probably the best approach for the initial efforts.
Absolutely.
Cheers!
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
^ permalink raw reply
* Re: [IPSEC]: Fix IP ID selection
From: David S. Miller @ 2006-04-28 22:23 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20060427115645.GA20140@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 27 Apr 2006 21:56:45 +1000
> I was looking through the xfrm input/output code in order to abstract
> out the address family specific encapsulation/decapsulation code. During
> that process I found this bug in the IP ID selection code in xfrm4_output.c.
>
> At that point dst is still the xfrm_dst for the current SA which
> represents an internal flow as far as the IPsec tunnel is concerned.
> Since the IP ID is going to sit on the outside of the encapsulated
> packet, we obviously want the external flow which is just dst->child.
>
> The fix is trivial.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks for catching this, applied, thanks Herbert.
^ permalink raw reply
* Re: [PATCH] fix unlikely usage in tcp_transmit_skb()
From: David S. Miller @ 2006-04-28 22:25 UTC (permalink / raw)
To: hzhong; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0604260947040.2907@localhost.localdomain>
From: Hua Zhong <hzhong@gmail.com>
Date: Wed, 26 Apr 2006 09:50:28 -0700 (PDT)
> [I hope this time it's OK - I'm sending from pine/Linux]
It adds an extra space in the diff lines which corrupts
the patch.
I've applied this by hand, but please try to get something
which works before providing new patches. Just try to email
yourself a patch, then try to apply it successfully yourself.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 22:38 UTC (permalink / raw)
To: rusty; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <1146261844.8029.54.camel@localhost.localdomain>
From: Rusty Russell <rusty@rustcorp.com.au>
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 is to effectively remove from (or flag) the established &
> listening hashes anything which could be effected by classifiers, so
> those packets get send through the default channel.
OK, when rules are installed, the socket channel mappings are
flushed. This is your idea right?
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 22:40 UTC (permalink / raw)
To: rusty; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <1146262622.8029.63.camel@localhost.localdomain>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Sat, 29 Apr 2006 08:17:01 +1000
> 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 greatly reduced because
> > it places the data in the cache immediately before the application
> > will in fact use the received data.
>
> Just to be clear here: I agree with Dave that without classifying
> hardware, there's no point (and much pain) in going all the way to
> userspace with the channel (ie. mmap). If you're going to copy anyway,
> might as well do it in the socket's read() call: then the user can then
> aim the copy exactly where they want, too. We'll need that TCP code in
> the kernel for the foreseeable future anyway 8)
>
> 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 do not think intelligent cards imply protocol in user space.
You can still get the zero copy, and moving the work to the
remote cpu, without all the complexity assosciated with putting
the protocol in userspace. It buys nothing but complexity.
> Side note: my Xen I/O patches allow the implementation of exactly this
> kind of virtual hardware (no coincidence 8), so intelligent cards might
> not be as far away as you think...
Such hardware can be prototyped in QEMU as well.
^ permalink raw reply
* Re: [RFC] Geographical/regulatory information for ieee80211
From: Harald Welte @ 2006-04-28 11:17 UTC (permalink / raw)
To: Larry Finger; +Cc: Rick Jones, Christoph Hellwig, netdev
In-Reply-To: <44501647.8070308@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
On Wed, Apr 26, 2006 at 07:54:31PM -0500, Larry Finger wrote:
> I am leaning toward putting the geographical information into a
> userland daemon.
I like that idea very much. This is all control metadate that doesn't
really need to be in the kernel.
> That way we won't have to patch the kernel every time a country
> modifies its regulations.
that's another advantage.
> In addition, the kernel will be smaller. The downside is that the
> daemon will have to be updated and supplied in some convenient form,
> perhaps as part of a wireless tools package.
Ideally the daemon would get the table of country restrictions from a
policy file (some human-readable ascii?). That file can then be
downloaded by a cronjob to keep it updated, if desired. A bit like the
PCI/USB device id databases...
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] [IPV6]: Fix race in route selection.
From: David S. Miller @ 2006-04-28 22:58 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <20060428.020456.35552581.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Fri, 28 Apr 2006 02:04:56 +0900 (JST)
> We eliminated rt6_dflt_lock (to protect default router pointer)
> at 2.6.17-rc1, and introduced rt6_select() for general router selection.
> The function is called in the context of rt6_lock read-lock held,
> but this means, we have some race conditions when we do round-robin.
>
> Am I correct?
>
> If so, we should put some spin_lock for serialization.
>
> Comments?
>
> Signed-off-by; YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
>
> Or, should we run whole part of rt6_select() under some lock?
I think the local lock will work and it is fine for now.
I will apply this as-is to fix the bug.
But in the longer term this seems a little bit heavy operation.
Perhaps there is some way to use "xchg()" here? It is just moving a
pointer around for a round robin list, if it could be reduced to just
a single pointer store, we could even do it without atomic operations.
^ permalink raw reply
* Re: [PATCH] fix unlikely usage in tcp_transmit_skb()
From: Alexey Toptygin @ 2006-04-28 23:45 UTC (permalink / raw)
To: David S. Miller; +Cc: hzhong, netdev
In-Reply-To: <20060428.152551.50641016.davem@davemloft.net>
On Fri, 28 Apr 2006, David S. Miller wrote:
> From: Hua Zhong <hzhong@gmail.com>
> Date: Wed, 26 Apr 2006 09:50:28 -0700 (PDT)
>
>> [I hope this time it's OK - I'm sending from pine/Linux]
>
> It adds an extra space in the diff lines which corrupts
> the patch.
You can work around this by enabling quell-flowed-text - then pine will
never mangle patches. Currently (pine4.64), if you're disabling flowed
text on a per-message basis with ^V before sending, patches containing
trailing whitespace will get mangled. Pine labels the message as not
flowed, but does the mangling anyway :-/
Tooting my own horn here, but I submitted a pine patch this week which
fixes the issue. Hopefully, the next pine release will behave correctly.
You'll still have to remember to hit ^V before sending mail containing
patches, and you should always use ^R to include patch files, since
newlines in the input are treated magically. Or, you can enable
quell-flowed-text, and pretend the whole flowed text feature never
happened. I'll shut up about pine now :-)
Alexey
^ permalink raw reply
* RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Caitlin Bestler @ 2006-04-28 23:45 UTC (permalink / raw)
To: David S. Miller, rusty; +Cc: johnpol, kelly, netdev
David S. Miller wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
> 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 is to effectively remove from (or flag) the established &
>> listening hashes anything which could be effected by classifiers, so
>> those packets get send through the default channel.
>
> OK, when rules are installed, the socket channel mappings are
> flushed. This is your idea right?
You mean when new rules are installed that would conflict with
an existing mapping, right?
Bumping every connection out of vj-channel mode whenever any new
rule was installed would be very counter-productive.
Ultimately, you only want a direct-to-user vj-channel when all
packets assigned to it would be passed by netchannels, and maybe
increment a single packet counter. Checking a single QoS rate
limiter may be possible too, but if there are more complex
rules then the channel has to be kept in kernel because it
wouldn't make sense to trust user-mode code to apply the
netchannel rules reliably.
^ permalink raw reply
* Re: Fw: Bug: PPP dropouts in >=2.6.16
From: Nuri Jawad @ 2006-04-29 0:05 UTC (permalink / raw)
To: Sven Schuster; +Cc: Andi Kleen, Jesse Brandeburg, Andrew Morton, netdev
In-Reply-To: <20060426060442.GA8875@zion.homelinux.com>
On Wed, 26 Apr 2006, Sven Schuster wrote:
> but don't hold your breath waiting for me, kernel compile
> takes more than two hours on my box :-)
Ouch. Takes 5/7 minutes here on the AMD64 resp. P4. Computer museum? :P
Anyhow, I tested PPP for 2.5 hours on the AMD64 the day before
yesterday with a bidirectional transfer that maxed out the upstream.
Last night, I additionally put some load on the CPU. Another 3 hours, no
problems whatsoever. Looks like the bug does not manifest on that system.
The next step will be to clone .config's settings as far as possible with
the different hardware and try again.
Regards,
Nuri
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Rusty Russell @ 2006-04-29 0:10 UTC (permalink / raw)
To: David S. Miller; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <20060428.153833.68265167.davem@davemloft.net>
On Fri, 2006-04-28 at 15:38 -0700, David S. Miller wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
> 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 is to effectively remove from (or flag) the established &
> > listening hashes anything which could be effected by classifiers, so
> > those packets get send through the default channel.
>
> OK, when rules are installed, the socket channel mappings are
> flushed. This is your idea right?
Yeah. First off, all flushed. Later on, we get selective.
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox