* Re: the future of ethtool
From: Ben Hutchings @ 2010-11-16 0:10 UTC (permalink / raw)
To: Thomas Graf; +Cc: Jeff Garzik, Stephen Hemminger, NetDev, David Miller
In-Reply-To: <20101115233335.GB24292@canuck.infradead.org>
On Mon, 2010-11-15 at 18:33 -0500, Thomas Graf wrote:
> On Mon, Nov 15, 2010 at 05:49:33PM -0500, Jeff Garzik wrote:
> > s/only// I don't think Stephen is suggesting sending _some_ ops
> > through netlink and others through old-ioctl. That's just silly.
> > Any new netlink interface should transit all existing ETHTOOL_xxx
> > commands/structures.
> >
> > But presumably, one would have the ability to send multiple
> > ETHTOOL_xxx bundled together into a single netlink transaction,
> > facilitating the kernel's calling of struct ethtool_ops'
> > ->begin()
> > ... first operation specified by userspace via netlink ...
> > ... second operation specified by userspace via netlink ...
> > ... etc.
> > ->end()
> >
> > The underlying struct ethtool_ops remains unchanged; you're only
> > changing the transit method.
> >
> > Thus, the ethtool userspace utility would switch entirely to
> > netlink, while the ioctl processing code remains for binary
> > compatibility.
> >
> > Or... ethtool userspace utility could remain unchanged, and a new
> > 'nictool' utility provides the same features but with (a) a new CLI
> > and (b) exclusively uses netlink rather than ioctl.
>
> I actually have code for this including userspace. I never submitted
> it because I wasn't confident it is the way to go since it literally
> duplicates all ethtool code in the kernel.
>
> There is one major problem with bundling multiple requests though. If
> one change request fails but other changes have been committed already
> we can't really undo them without causing lots of races. We have to
> leave the device in a somewhat inconsistent state. It's even difficult
> to tell what has been comitted and what hasn't. It also makes error
> reporting more difficult as a -ERANGE error code could apply to any
> of the values to be changed.
[...]
I think it's hopeless to make this truly transactional. Unless the
ethtool core maintains all the settings in one giant structure and
passes them over to the driver to check and apply then there is no way
driver authors are going to get it right in general. And if the ethtool
core does that then, as you say, error reporting is going to be
terrible. There will be even more need to go look in the kernel log to
see the driver's explanation of why the settings are invalid which was
too long to fit in this margin^Wreturn code.
I would expect to treat each operation in a multiple-set as conditional
on the success of all previous operations. ethtool or other utilities
should then take care to put operations in a sensible order (e.g. enable
TX checksum before TSO, if those remain separate operations). Error
reporting in the core is then as simple as reporting how many operations
were successful plus the error code for the one that failed.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2010-11-16 0:34 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Jesse Gross
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
Hi all,
After merging the net tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
ERROR: "netif_get_vlan_features" [drivers/net/xen-netfront.ko] undefined!
Caused by commit 58e998c6d23988490162cef0784b19ea274d90bb ("offloading:
Force software GSO for multiple vlan tags").
Presumably netif_get_vlan_features needs exporting.
I have used the net tree from next-20101115 for today (with
1d7138de878d1d4210727c1200193e69596f93b3 reverted).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* patchwork deferred?
From: Joe Perches @ 2010-11-16 1:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Now that net-next is open, should patches with patchwork
status "deferred" be resubmitted?
^ permalink raw reply
* Re: [PATCH] net: use the macros defined for the members of flowi
From: David Miller @ 2010-11-16 1:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: brian.haley, xiaosuo, netdev
In-Reply-To: <1289857126.3364.14.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 15 Nov 2010 22:38:46 +0100
> Le lundi 15 novembre 2010 à 16:33 -0500, Brian Haley a écrit :
>> On 11/12/2010 11:43 PM, Changli Gao wrote:
>> > Use the macros defined for the members of flowi to clean the code up.
>> >
>> > diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
>> > index 865fd76..36cd0b7 100644
>> > --- a/net/bridge/br_netfilter.c
>> > +++ b/net/bridge/br_netfilter.c
>> > @@ -412,13 +412,8 @@ static int br_nf_pre_routing_finish(struct sk_buff *skb)
>> > if (dnat_took_place(skb)) {
>> > if ((err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev))) {
>> > struct flowi fl = {
>> > - .nl_u = {
>> > - .ip4_u = {
>> > - .daddr = iph->daddr,
>> > - .saddr = 0,
>> > - .tos = RT_TOS(iph->tos) },
>> > - },
>> > - .proto = 0,
>> > + .fl4_dst = iph->daddr,
>> > + .fl4_tos = RT_TOS(iph->tos),
>> > };
>>
>> Are these actually equivalent? You dropped two assignments to zero.
>> I always thought things on the stack weren't.
>
> Same question on lkml few hours ago. I think gcc does the assignement to
> zero, even on automatic variables (at least done on x86), but could not
> find a doc on it.
It always has, it always will. "type var = { };" always zeros
out the structure.
^ permalink raw reply
* Re: the future of ethtool
From: David Miller @ 2010-11-16 2:02 UTC (permalink / raw)
To: tgraf; +Cc: jeff, bhutchings, shemminger, netdev
In-Reply-To: <20101115233335.GB24292@canuck.infradead.org>
From: Thomas Graf <tgraf@infradead.org>
Date: Mon, 15 Nov 2010 18:33:35 -0500
> I tried to solve this by splitting the validate/change operation and
> thus be able to validate all requests before starting to commit
> them. This would mean changing all drivers though which I wasn't
> willing to do.
It isn't sufficient. You can still get into unwindable failures.
Earlier operations can consume fixed resources like TCAM filter
slots or rx/tx queues, making a subsequent operation in the
sequence fail.
A validate/commit scheme cannot detect this effectively.
^ permalink raw reply
* Re: patchwork deferred?
From: David Miller @ 2010-11-16 2:04 UTC (permalink / raw)
To: joe; +Cc: netdev
In-Reply-To: <1289869813.16461.173.camel@Joe-Laptop>
From: Joe Perches <joe@perches.com>
Date: Mon, 15 Nov 2010 17:10:13 -0800
> Now that net-next is open, should patches with patchwork
> status "deferred" be resubmitted?
>From you, no, you're already consuming the bulk of my queue
and I'd like you to slow down so I can spend time on the
more neuron intensive patches.
Thanks.
^ permalink raw reply
* Re: network device reference leak with net-next
From: David Miller @ 2010-11-16 2:06 UTC (permalink / raw)
To: eric.dumazet
Cc: john.r.fastabend, shemminger, lorenzo, netdev, brian.haley, maze
In-Reply-To: <1289863543.3364.24.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 16 Nov 2010 00:25:43 +0100
> Le lundi 15 novembre 2010 à 15:18 -0800, John Fastabend a écrit :
>> With a quick hack the above seems to resolve the issue but I'll need to review the ipv6 stuff to be sure this is sane.
>>
>> Thanks,
>> John.
>
> Your machine is faster than mine ;)
>
> Yes this commit seems buggy, thanks for finding the problem !
Indeed, thanks John. Please send a final fix after you've done
your review.
Thanks again!
^ permalink raw reply
* Re: [net-2.6 PATCH] nete zero kobject in rx_queue_release
From: John Fastabend @ 2010-11-16 2:06 UTC (permalink / raw)
To: David Miller
Cc: therbert@google.com, netdev@vger.kernel.org,
eric.dumazet@gmail.com
In-Reply-To: <20101114.151529.183053743.davem@davemloft.net>
On 11/14/2010 3:15 PM, David Miller wrote:
> From: Tom Herbert <therbert@google.com>
> Date: Sun, 14 Nov 2010 14:40:00 -0800
>
>>> So we'll need something like:
>>>
>>> if (atomic_dec_and_test(&first->count))
>>> kfree(first);
>>> else
>>> /* clear everything except queue->first */
>>>
>>
>> The patches to get rid of the separate refcnt should obviate this
>> complexity. Could just clear the queue in kobject release.
>
> True but we'll still need a patch for older kernels.
OK Thanks. I'll have a stable patch and a net-2.6 patch soon.
-- John
^ permalink raw reply
* Re: patchwork deferred?
From: Joe Perches @ 2010-11-16 2:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20101115.180419.112575212.davem@davemloft.net>
On Mon, 2010-11-15 at 18:04 -0800, David Miller wrote:
> I'd like you to slow down so I can spend time on the
> more neuron intensive patches.
No worries. I'll wait awhile before submitting any
new net drivers/net trivia patches.
^ permalink raw reply
* Re: Remaining problems in firewire-net
From: Maxim Levitsky @ 2010-11-16 3:31 UTC (permalink / raw)
To: Stefan Richter; +Cc: netdev, linux1394-devel, linux-kernel
In-Reply-To: <20101115090103.0df0b5ef@stein>
On Mon, 2010-11-15 at 09:01 +0100, Stefan Richter wrote:
> On Nov 15 Maxim Levitsky wrote:
> > That is because 1394 spec specifies that first of all the ISO channel
> > must be allocated from the IRM node. The firewire stack currently just
> > uses hardcoded numbers in two places the ISO is used
> > (firewire-net, and firedtv)
> > However it has all functions implemented for this.
>
> This is a bug (missing feature) in firedtv but not in firewire-net. The
> broadcast channel is allocated and reallocated by the bus manager, not
> by an IP-over-1394 user. But you found that out already, below.
Agree fully.
>
> Channel allocation and DMA context allocation and control are unrelated
> issues, on the other hand. One is a higher-level cooperative protocol
> for bus-wide resource management (in which the nodes' roles are defined
> in various different ways by protocols such as AV/C's CMP or by IIDC).
> The other is about hardware control locally in the OHCI bus bridge
> hardware.
>
> [...]
> > In case of firewire-net, it is simpler, because it uses the broadcast
> > channel, so it only has to find who is the IRM and read its
> > BROADCAST_CHANNEL.
> >
> > However, I think I need to write a function to query the IRM its
> > broadcast channel, don't think it has one.
>
> Overkill. Just leave it as is:
> 1.) We know which number the broadcast channel has.
> 2.) We optimistically assume that a 1394a compliant IRM or bus
> manager exists and allocated that channel.
>
> Why introduce entirely unnecessary fragility?
Looking at spec again, indeed 31 the the default broadcast channel, and
probably nobody ever changes it by writing the BROADCAST_CHANNEL.
The BROADCAST_CHANNEL register was actually added in 1394a.
>
> > Speaking of IRM discovery, the spec says it should be a node with
> > contender bit and largest node id. However, the code in
> > core-topology.c, build_tree seems to take the node that sent the
> > selfID packet last.
>
> This is because of a monotony rule of how self ID packets arrive during
> self identification phase.
Ah, ok, found this bit in spec too.
Btw, according to spec the firewire appears to be half-duplex.
Also one note I wanted to say in previous mail. but forgot.
The IP over 1394 tells that unicast can also use ISO transactions.
However, it doesn't say how to negotiate the ISO channel number, thus a
logical conclusion is that its not possible to use ISO transactions for
unicast.
Is that right?
Best regards,
Maxim Levitsky
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: David Miller @ 2010-11-16 4:15 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, jesse
In-Reply-To: <20101116113437.4f536d16.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 16 Nov 2010 11:34:37 +1100
> After merging the net tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> ERROR: "netif_get_vlan_features" [drivers/net/xen-netfront.ko] undefined!
>
> Caused by commit 58e998c6d23988490162cef0784b19ea274d90bb ("offloading:
> Force software GSO for multiple vlan tags").
>
> Presumably netif_get_vlan_features needs exporting.
Thanks Stephen, I've just pushed the following fix.
--------------------
net: Export netif_get_vlan_features().
ERROR: "netif_get_vlan_features" [drivers/net/xen-netfront.ko] undefined!
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/core/dev.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 8725d16..381b8e2 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1983,6 +1983,7 @@ int netif_get_vlan_features(struct sk_buff *skb, struct net_device *dev)
else
return 0;
}
+EXPORT_SYMBOL(netif_get_vlan_features);
/*
* Returns true if either:
--
1.7.3.2
^ permalink raw reply related
* [PATCH] net/unix: Allow Unix sockets to be treated like normal files.
From: Jeff Hansen @ 2010-11-16 4:23 UTC (permalink / raw)
To: netdev; +Cc: Dave Miller, Jeff Hansen
This is an update to my previous patch that fixes crashes on systems that
used filp->private_data for their own purposes.
For some reason, it doesn't look like this will ever get main-lined. But,
just in case someone wants to be able to write to a Unix socket with:
$ echo send_cmd > /tmp/my_socket
This is the patch that will let you do that.
This allows Unix sockets to be opened, written, read, and closed, like
normal files. This can be especially handy from, for example, a shell
script that wants to send a short message to a Unix socket, but doesn't
want to and/or cannot create the socket itself.
Signed-off-by: Jeff Hansen <x@jeffhansen.com>
---
net/unix/Kconfig | 10 +++
net/unix/af_unix.c | 177 ++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 187 insertions(+), 0 deletions(-)
diff --git a/net/unix/Kconfig b/net/unix/Kconfig
index 5a69733..68df4f1 100644
--- a/net/unix/Kconfig
+++ b/net/unix/Kconfig
@@ -19,3 +19,13 @@ config UNIX
Say Y unless you know what you are doing.
+config UNIX_FOPS
+ boolean "Allow Unix sockets to be treated like normal files"
+ depends on UNIX
+ ---help---
+ If you say Y here, Unix sockets may be opened, written, read, and
+ closed, like normal files. This is handy for sending short commands
+ to Unix sockets (i.e. from shell scripts), without having to create
+ a Unix socket.
+
+ Say Y unless you know what you are doing.
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 0ebc777..81ba74d 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -798,6 +798,178 @@ fail:
return NULL;
}
+#ifdef CONFIG_UNIX_FOPS
+struct sock *unix_fops_find_by_filp(struct file *filp,
+ struct sockaddr_un *sunaddr, unsigned int *_alen)
+{
+ int hash, nlen, alen, retval;
+ struct sock *sock = NULL;
+ struct net *net = &init_net;
+ char *p;
+ struct dentry *dentry = filp->f_dentry;
+
+ retval = -EINVAL;
+ if (!filp)
+ goto error;
+ dentry = filp->f_dentry;
+
+ if (!dentry || !dentry->d_parent)
+ goto error;
+
+ sunaddr->sun_family = AF_UNIX;
+ p = d_path(&filp->f_path, sunaddr->sun_path, sizeof(sunaddr->sun_path));
+ if (IS_ERR(p))
+ return (void *)p;
+ if (!p)
+ goto error;
+ nlen = strnlen(p, sizeof(sunaddr->sun_path) -
+ (p - sunaddr->sun_path));
+
+ memmove(sunaddr->sun_path, p, nlen);
+ alen = nlen;
+ if (nlen < sizeof(sunaddr->sun_path)) {
+ sunaddr->sun_path[nlen] = 0;
+ alen++;
+ }
+ alen += sizeof(sunaddr->sun_family);
+
+ if (_alen)
+ *_alen = alen;
+
+ hash = dentry->d_inode->i_ino & (UNIX_HASH_SIZE-1);
+ sock = unix_find_socket_byname(net, sunaddr, alen, 0, hash);
+
+error:
+ if (sock)
+ return sock;
+ else
+ return ERR_PTR(retval);
+}
+
+static int unix_open(struct inode *inode, struct file *filp)
+{
+ int err, alen;
+ struct socket *sock = NULL;
+ struct sock *usock;
+ struct unix_sock *u = NULL;
+ struct sockaddr_un sunaddr = { 0 };
+
+ usock = unix_fops_find_by_filp(filp, &sunaddr, &alen);
+ if (IS_ERR(usock))
+ return PTR_ERR(usock);
+ u = unix_sk(usock);
+ err = -EBUSY;
+ if (u->fops_socket)
+ goto error;
+
+ err = sock_create_kern(PF_UNIX, usock->sk_type, 0, &sock);
+ if (err)
+ goto error;
+
+ err = sock->ops->connect(sock, (struct sockaddr *)&sunaddr,
+ alen, 0);
+ if (err) {
+ sock_release(sock);
+ goto error;
+ }
+ u->fops_socket = sock;
+
+ /* FALLTHROUGH */
+error:
+ sock_put(usock);
+
+ return err;
+}
+
+static int unix_frelease(struct inode *inode, struct file *filp)
+{
+ int retval;
+ struct socket *sock;
+ struct sock *usock;
+ struct unix_sock *u;
+ struct sockaddr_un sunaddr;
+
+ usock = unix_fops_find_by_filp(filp, &sunaddr, NULL);
+ if (IS_ERR(usock))
+ return PTR_ERR(usock);
+ u = unix_sk(usock);
+ sock = u->fops_socket;
+ retval = -EINVAL;
+ if (!sock)
+ goto error;
+ u->fops_socket = NULL;
+ sock_release(sock);
+ retval = 0;
+
+ /* FALLTHROUGH */
+error:
+ sock_put(usock);
+ return retval;
+}
+
+static ssize_t unix_readwrite(struct file *filp, void *buf,
+ size_t _len, loff_t *ppos, int do_write)
+{
+ int len = (int)_len, err = 0;
+ struct kvec iov = {
+ .iov_base = buf,
+ .iov_len = len,
+ };
+ struct msghdr msg = {
+ /* NB: struct iovec and kvec are equal */
+ .msg_iov = (struct iovec *)&iov,
+ .msg_iovlen = 1,
+ };
+ struct socket *sock;
+ struct sock *usock;
+ struct unix_sock *u;
+ struct sockaddr_un sunaddr;
+
+ usock = unix_fops_find_by_filp(filp, &sunaddr, NULL);
+ if (IS_ERR(usock))
+ return PTR_ERR(usock);
+ u = unix_sk(usock);
+ sock = u->fops_socket;
+ err = -EINVAL;
+ if (!sock)
+ goto error;
+
+ err = -E2BIG;
+ if (_len > 0xffffffffLL)
+ goto error;
+
+ err = do_write ? sock_sendmsg(sock, &msg, len) :
+ sock_recvmsg(sock, &msg, len, 0);
+ if (err > 0 && ppos)
+ *ppos += err;
+
+ /* FALLTHROUGH */
+error:
+ sock_put(usock);
+
+ return err;
+}
+
+static ssize_t unix_write(struct file *filp, const char __user *buf,
+ size_t _len, loff_t *ppos)
+{
+ return unix_readwrite(filp, (void *)buf, _len, ppos, 1);
+}
+
+static ssize_t unix_read(struct file *filp, char __user *buf,
+ size_t _len, loff_t *ppos)
+{
+ return unix_readwrite(filp, (void *)buf, _len, ppos, 0);
+}
+
+const struct file_operations unix_sock_fops = {
+ .owner = THIS_MODULE,
+ .open = unix_open,
+ .release = unix_frelease,
+ .write = unix_write,
+ .read = unix_read,
+};
+#endif /* CONFIG_UNIX_FOPS */
static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
{
@@ -874,6 +1046,11 @@ out_mknod_drop_write:
mnt_drop_write(nd.path.mnt);
if (err)
goto out_mknod_dput;
+
+#ifdef CONFIG_UNIX_FOPS
+ dentry->d_inode->i_fop = &unix_sock_fops;
+#endif
+
mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
dput(nd.path.dentry);
nd.path.dentry = dentry;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Add Flow control,
From: Tomoya MORINAGA @ 2010-11-16 5:18 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w, Masayuki Ohtake,
Samuel Ortiz, margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, LKML,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, Wolfgang Grandegger,
joel.clark-ral2JQCrhuEAvxtiuMwx3w, David S. Miller,
Christian Pellegrin, qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CE0F92A.40308@pengutronix.de>
On Monday, November 15, 2010 6:11 PM, Marc Kleine-Budde wrote:
> Please make it one patch per topic. A review of your patch will follow.
It's too late now.
This is difficult to separete patch per topic from current our CAN driver.
Next time posting another patch, I will do like so.
---
Thanks,
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Add Flow control,
From: Tomoya MORINAGA @ 2010-11-16 5:30 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w, Masayuki Ohtake,
Samuel Ortiz, margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, LKML,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, Wolfgang Grandegger,
joel.clark-ral2JQCrhuEAvxtiuMwx3w, David S. Miller,
Christian Pellegrin, qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CE0FF5A.3000100@pengutronix.de>
Hi Marc,
On Monday, November 15, 2010 6:37 PM, Marc Kleine-Budde wrote :
> Either use ioread8 or ioread16 in both the rx and tx path.
I will modify to ioread16
>> + if (ioread32(&priv->regs->treq2) & 0xfc00) {
> what does this if check?
This is for whether all tx requests are complete or not.
---
Thanks,
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
^ permalink raw reply
* [PATCH net-next-2.6] udp: use atomic_inc_not_zero_hint
From: Eric Dumazet @ 2010-11-16 5:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev
UDP sockets refcount is usually 2, unless an incoming frame is going to
be queued in receive or backlog queue.
Using atomic_inc_not_zero_hint() permits to reduce latency, because
processor issues less memory transactions.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/sock.h | 2 +-
net/ipv4/udp.c | 4 ++--
net/ipv6/udp.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index a6338d0..eb0c1f5 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -57,7 +57,7 @@
#include <linux/rculist_nulls.h>
#include <linux/poll.h>
-#include <asm/atomic.h>
+#include <linux/atomic.h>
#include <net/dst.h>
#include <net/checksum.h>
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 5e0a3a5..491ecd3 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -430,7 +430,7 @@ begin:
if (result) {
exact_match:
- if (unlikely(!atomic_inc_not_zero(&result->sk_refcnt)))
+ if (unlikely(!atomic_inc_not_zero_hint(&result->sk_refcnt, 2)))
result = NULL;
else if (unlikely(compute_score2(result, net, saddr, sport,
daddr, hnum, dif) < badness)) {
@@ -500,7 +500,7 @@ begin:
goto begin;
if (result) {
- if (unlikely(!atomic_inc_not_zero(&result->sk_refcnt)))
+ if (unlikely(!atomic_inc_not_zero_hint(&result->sk_refcnt, 2)))
result = NULL;
else if (unlikely(compute_score(result, net, saddr, hnum, sport,
daddr, dport, dif) < badness)) {
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 91def93..b541a4e 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -227,7 +227,7 @@ begin:
if (result) {
exact_match:
- if (unlikely(!atomic_inc_not_zero(&result->sk_refcnt)))
+ if (unlikely(!atomic_inc_not_zero_hint(&result->sk_refcnt, 2)))
result = NULL;
else if (unlikely(compute_score2(result, net, saddr, sport,
daddr, hnum, dif) < badness)) {
@@ -294,7 +294,7 @@ begin:
goto begin;
if (result) {
- if (unlikely(!atomic_inc_not_zero(&result->sk_refcnt)))
+ if (unlikely(!atomic_inc_not_zero_hint(&result->sk_refcnt, 2)))
result = NULL;
else if (unlikely(compute_score(result, net, hnum, saddr, sport,
daddr, dport, dif) < badness)) {
^ permalink raw reply related
* Re: the future of ethtool
From: Thomas Graf @ 2010-11-16 6:17 UTC (permalink / raw)
To: David Miller; +Cc: jeff, bhutchings, shemminger, netdev
In-Reply-To: <20101115.180225.189678628.davem@davemloft.net>
On Mon, Nov 15, 2010 at 06:02:25PM -0800, David Miller wrote:
> It isn't sufficient. You can still get into unwindable failures.
>
> Earlier operations can consume fixed resources like TCAM filter
> slots or rx/tx queues, making a subsequent operation in the
> sequence fail.
>
> A validate/commit scheme cannot detect this effectively.
I agree, there are many more scenarios where it would not work
reliably. It would have ensured that all provided values are
within range boundries and that all requested operations are in
fact supported. Since I have disregarded the idea, I does not
matter much anymore.
^ permalink raw reply
* Re: Fwd: a Great Idea - include Kademlia networking protocol in kernel -- REVISITED
From: Marcos @ 2010-11-16 6:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1289727544.2743.72.camel@edumazet-laptop>
[Eric Dumazet wrote:]
> But we dont want a "super operating system". We want a good one.
Yes, well you have that, I think, speaking at the kernel level. But
the thing is, people are building tools that mimic such anyway, and
the next wave of new value will be found there.
> Memory stores done in userland are as fast as memory stores done in
> kernel.
Really? And how about the abstraction-level? because that will either
make it lucrative or not for developers to build applications for
it.....
> Once you need to access files, perform complex searches, timers,
> logging, and all the stuff, you really want to do it from userland, in
> high level language that many programmers master, or get something that
> is too complex/buggy.
Yes, of course, all that will have to be considered. But I'm
suggesting that such a move is an investment in the future, that the
the number of machines that will want or request peer-2-peer
connectivity will (or should) only increase. Done right, such a move
should *simplify* things. We're biased to think in centralized ways
because of the centuries-old history of *who* has the resources. But
as networking, computation, and storage become commodified further,
whole new topologies for the *right* architecture become available.
The idea of "the OS" itself morphs. And the *only* way maximize the
value of the network is to make it easy to connect and communicate
between peers -- what happens after that is so radical it can hardly
be speculated because it gets into the realm of emergent complexity.
Again, I refer you to Reed's law on the value of such networks.
marcos
^ permalink raw reply
* Re: the future of ethtool
From: Thomas Graf @ 2010-11-16 6:25 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Jeff Garzik, Stephen Hemminger, NetDev, David Miller
In-Reply-To: <1289866230.2586.65.camel@bwh-desktop>
On Tue, Nov 16, 2010 at 12:10:30AM +0000, Ben Hutchings wrote:
> I would expect to treat each operation in a multiple-set as conditional
> on the success of all previous operations. ethtool or other utilities
> should then take care to put operations in a sensible order (e.g. enable
> TX checksum before TSO, if those remain separate operations). Error
> reporting in the core is then as simple as reporting how many operations
> were successful plus the error code for the one that failed.
This is already not that trivial with current netlink limitations.
We are pretty much limited to a single int when returning error
states. One more reason to rethink current netlink error semantics.
^ permalink raw reply
* [net-2.6 PATCH] ipv6: fix missing in6_ifa_put in addrconf
From: John Fastabend @ 2010-11-16 6:29 UTC (permalink / raw)
To: davem; +Cc: john.r.fastabend, eric.dumazet, netdev, shemminger
Fix ref count bug introduced by
commit 2de795707294972f6c34bae9de713e502c431296
Author: Lorenzo Colitti <lorenzo@google.com>
Date: Wed Oct 27 18:16:49 2010 +0000
ipv6: addrconf: don't remove address state on ifdown if the address
is being kept
Fix logic so that addrconf_ifdown() decrements the inet6_ifaddr
refcnt correctly with in6_ifa_put().
Reported-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
net/ipv6/addrconf.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index b41ce0f..aaa3ca4 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2754,13 +2754,13 @@ static int addrconf_ifdown(struct net_device *dev, int how)
ifa->state = INET6_IFADDR_STATE_DEAD;
spin_unlock_bh(&ifa->state_lock);
- if (state == INET6_IFADDR_STATE_DEAD) {
- in6_ifa_put(ifa);
- } else {
+ if (state != INET6_IFADDR_STATE_DEAD) {
__ipv6_ifa_notify(RTM_DELADDR, ifa);
atomic_notifier_call_chain(&inet6addr_chain,
NETDEV_DOWN, ifa);
}
+
+ in6_ifa_put(ifa);
write_lock_bh(&idev->lock);
}
}
^ permalink raw reply related
* ipvs: ipvs update for nf-next-2.6
From: Simon Horman @ 2010-11-16 6:34 UTC (permalink / raw)
To: Eric Dumazet, Hans Schillstrom, Julian Anastasov, Patrick McHardy,
lvs-devel, n
Hi Patrick,
the following patches contain updates to IPVS since 2.6.37-rc1
and are targeted at nf-next-2.6.
- Static and shadow variable clean-ups from Eric
- Preparation for persistence engine syncrhonisation
- Correctness fix for persistence engine match.
I do not consider this a bug as it can only manifest in a problem
if there is more than one persistence engine loaded and
currently only one exists.
- Code cleanps for ip_vs_sync_conn(), ip_vs_process_message()
and ip_vs_process_message()
- Handle GRO aggregated skbs
The previous behaviour was to send a needs frag ICMP.
This is probably stable material.
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git for-patrick
I expect more activity before 2.6.37-rc1. In particular Hans is working
heavily with Julian and myself on the new synchronisation code.
^ permalink raw reply
* [PATCH 1/6] IPVS: Only match pe_data created by the same pe
From: Simon Horman @ 2010-11-16 6:34 UTC (permalink / raw)
To: Eric Dumazet, Hans Schillstrom, Julian Anastasov, Patrick McHardy,
lvs-devel, n
Cc: Simon Horman
In-Reply-To: <1289889298-17287-1-git-send-email-horms@verge.net.au>
Only match persistence engine data if it was
created by the same persistence engine.
Reported-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_conn.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index 64a9ca3..261db1a 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -354,7 +354,7 @@ struct ip_vs_conn *ip_vs_ct_in_get(const struct ip_vs_conn_param *p)
list_for_each_entry(cp, &ip_vs_conn_tab[hash], c_list) {
if (p->pe_data && p->pe->ct_match) {
- if (p->pe->ct_match(p, cp))
+ if (p->pe == cp->pe && p->pe->ct_match(p, cp))
goto out;
continue;
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/6] IPVS: Make the cp argument to ip_vs_sync_conn() static
From: Simon Horman @ 2010-11-16 6:34 UTC (permalink / raw)
To: Eric Dumazet, Hans Schillstrom, Julian Anastasov, Patrick McHardy,
lvs-devel, n
Cc: Simon Horman
In-Reply-To: <1289889298-17287-1-git-send-email-horms@verge.net.au>
Acked-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
include/net/ip_vs.h | 2 +-
net/netfilter/ipvs/ip_vs_sync.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index be2b569..d5a32e4 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -916,7 +916,7 @@ extern char ip_vs_master_mcast_ifn[IP_VS_IFNAME_MAXLEN];
extern char ip_vs_backup_mcast_ifn[IP_VS_IFNAME_MAXLEN];
extern int start_sync_thread(int state, char *mcast_ifn, __u8 syncid);
extern int stop_sync_thread(int state);
-extern void ip_vs_sync_conn(struct ip_vs_conn *cp);
+extern void ip_vs_sync_conn(const struct ip_vs_conn *cp);
/*
diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
index ab85aed..a4dccbc 100644
--- a/net/netfilter/ipvs/ip_vs_sync.c
+++ b/net/netfilter/ipvs/ip_vs_sync.c
@@ -236,7 +236,7 @@ get_curr_sync_buff(unsigned long time)
* Add an ip_vs_conn information into the current sync_buff.
* Called by ip_vs_in.
*/
-void ip_vs_sync_conn(struct ip_vs_conn *cp)
+void ip_vs_sync_conn(const struct ip_vs_conn *cp)
{
struct ip_vs_sync_mesg *m;
struct ip_vs_sync_conn *s;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/6] IPVS: Remove useless { } block from ip_vs_process_message()
From: Simon Horman @ 2010-11-16 6:34 UTC (permalink / raw)
To: Eric Dumazet, Hans Schillstrom, Julian Anastasov, Patrick McHardy,
lvs-devel, n
Cc: Simon Horman
In-Reply-To: <1289889298-17287-1-git-send-email-horms@verge.net.au>
Acked-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_sync.c | 24 +++++++++++-------------
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
index a4dccbc..72b3d88 100644
--- a/net/netfilter/ipvs/ip_vs_sync.c
+++ b/net/netfilter/ipvs/ip_vs_sync.c
@@ -381,20 +381,18 @@ static void ip_vs_process_message(const char *buffer, const size_t buflen)
}
}
- {
- if (ip_vs_conn_fill_param_sync(AF_INET, s->protocol,
- (union nf_inet_addr *)&s->caddr,
- s->cport,
- (union nf_inet_addr *)&s->vaddr,
- s->vport, ¶m)) {
- pr_err("ip_vs_conn_fill_param_sync failed");
- return;
- }
- if (!(flags & IP_VS_CONN_F_TEMPLATE))
- cp = ip_vs_conn_in_get(¶m);
- else
- cp = ip_vs_ct_in_get(¶m);
+ if (ip_vs_conn_fill_param_sync(AF_INET, s->protocol,
+ (union nf_inet_addr *)&s->caddr,
+ s->cport,
+ (union nf_inet_addr *)&s->vaddr,
+ s->vport, ¶m)) {
+ pr_err("ip_vs_conn_fill_param_sync failed");
+ return;
}
+ if (!(flags & IP_VS_CONN_F_TEMPLATE))
+ cp = ip_vs_conn_in_get(¶m);
+ else
+ cp = ip_vs_ct_in_get(¶m);
if (!cp) {
/*
* Find the appropriate destination for the connection.
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/6] IPVS: buffer argument to ip_vs_process_message() should not be const
From: Simon Horman @ 2010-11-16 6:34 UTC (permalink / raw)
To: Eric Dumazet, Hans Schillstrom, Julian Anastasov, Patrick McHardy,
lvs-devel, n
Cc: Simon Horman
In-Reply-To: <1289889298-17287-1-git-send-email-horms@verge.net.au>
It is assigned to a non-const variable and its contents are modified.
Acked-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_sync.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
index 72b3d88..3897d6b 100644
--- a/net/netfilter/ipvs/ip_vs_sync.c
+++ b/net/netfilter/ipvs/ip_vs_sync.c
@@ -303,7 +303,7 @@ ip_vs_conn_fill_param_sync(int af, int protocol,
* Process received multicast message and create the corresponding
* ip_vs_conn entries.
*/
-static void ip_vs_process_message(const char *buffer, const size_t buflen)
+static void ip_vs_process_message(char *buffer, const size_t buflen)
{
struct ip_vs_sync_mesg *m = (struct ip_vs_sync_mesg *)buffer;
struct ip_vs_sync_conn *s;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 5/6] ipvs: add static and read_mostly attributes
From: Simon Horman @ 2010-11-16 6:34 UTC (permalink / raw)
To: Eric Dumazet, Hans Schillstrom, Julian Anastasov, Patrick McHardy,
lvs-devel, n
Cc: Eric Dumazet, Simon Horman
In-Reply-To: <1289889298-17287-1-git-send-email-horms@verge.net.au>
From: Eric Dumazet <eric.dumazet@gmail.com>
ip_vs_conn_tab_bits & ip_vs_conn_tab_mask are static to
ipvs/ip_vs_conn.c
ip_vs_conn_tab_size, ip_vs_conn_tab_mask, ip_vs_conn_tab [the pointer],
ip_vs_conn_rnd are mostly read.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_conn.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index 261db1a..7615f9e 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -48,18 +48,18 @@
/*
* Connection hash size. Default is what was selected at compile time.
*/
-int ip_vs_conn_tab_bits = CONFIG_IP_VS_TAB_BITS;
+static int ip_vs_conn_tab_bits = CONFIG_IP_VS_TAB_BITS;
module_param_named(conn_tab_bits, ip_vs_conn_tab_bits, int, 0444);
MODULE_PARM_DESC(conn_tab_bits, "Set connections' hash size");
/* size and mask values */
-int ip_vs_conn_tab_size;
-int ip_vs_conn_tab_mask;
+int ip_vs_conn_tab_size __read_mostly;
+static int ip_vs_conn_tab_mask __read_mostly;
/*
* Connection hash table: for input and output packets lookups of IPVS
*/
-static struct list_head *ip_vs_conn_tab;
+static struct list_head *ip_vs_conn_tab __read_mostly;
/* SLAB cache for IPVS connections */
static struct kmem_cache *ip_vs_conn_cachep __read_mostly;
@@ -71,7 +71,7 @@ static atomic_t ip_vs_conn_count = ATOMIC_INIT(0);
static atomic_t ip_vs_conn_no_cport_cnt = ATOMIC_INIT(0);
/* random value for IPVS connection hash */
-static unsigned int ip_vs_conn_rnd;
+static unsigned int ip_vs_conn_rnd __read_mostly;
/*
* Fine locking granularity for big connection hash table
--
1.7.2.3
^ permalink raw reply related
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