* [PATCH v7 2/7] SUNRPC: use rpcbind reference counting helpers
From: Stanislav Kinsbursky @ 2011-10-28 11:52 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem,
devel
In-Reply-To: <20111028104530.24628.23631.stgit@localhost6.localdomain6>
All is simple: we just increase users counter if rpcbind clients has been
created already. Otherwise we create them and set users counter to 1.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/rpcb_clnt.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index 9830d87..115df11 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -258,9 +258,7 @@ static int rpcb_create_local_unix(void)
clnt4 = NULL;
}
- /* Protected by rpcb_create_local_mutex */
- rpcb_local_clnt = clnt;
- rpcb_local_clnt4 = clnt4;
+ rpcb_set_local(clnt, clnt4);
out:
return result;
@@ -312,9 +310,7 @@ static int rpcb_create_local_net(void)
clnt4 = NULL;
}
- /* Protected by rpcb_create_local_mutex */
- rpcb_local_clnt = clnt;
- rpcb_local_clnt4 = clnt4;
+ rpcb_set_local(clnt, clnt4);
out:
return result;
@@ -329,11 +325,11 @@ static int rpcb_create_local(void)
static DEFINE_MUTEX(rpcb_create_local_mutex);
int result = 0;
- if (rpcb_local_clnt)
+ if (rpcb_get_local())
return result;
mutex_lock(&rpcb_create_local_mutex);
- if (rpcb_local_clnt)
+ if (rpcb_get_local())
goto out;
if (rpcb_create_local_unix() != 0)
^ permalink raw reply related
* [PATCH v7 0/7] SUNRPC: make rpcbind clients allocated and destroyed dynamically
From: Stanislav Kinsbursky @ 2011-10-28 11:52 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem,
devel
This patch-set was created in context of clone of git branch:
git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git
and rebased on tag "v3.1".
v7:
1) Implemented "goto pattern" in __svc_create().
2) Pathes 5 and 6 from perious patch-set were squashed to make things looks
clearer and to allow safe bisecting of the patch-set.
v6:
1) Fixes in rpcb_clients management.
v4:
1) creation and destruction on rpcbind clients now depends on service program
versions "vs_hidden" flag.
This patch is required for further RPC layer virtualization, because rpcbind
clients have to be per network namespace.
To achive this, we have to untie network namespace from rpcbind clients sockets.
The idea of this patch set is to make rpcbind clients non-static. I.e. rpcbind
clients will be created during first RPC service creation, and destroyed when
last RPC service is stopped.
With this patch set rpcbind clients can be virtualized easely.
The following series consists of:
---
Stanislav Kinsbursky (7):
SUNRPC: introduce helpers for reference counted rpcbind clients
SUNRPC: use rpcbind reference counting helpers
SUNRPC: introduce svc helpers for prepairing rpcbind infrastructure
SUNRPC: setup rpcbind clients if service requires it
SUNRPC: cleanup service destruction
SUNRPC: remove rpcbind clients creation during service registering
SUNRPC: remove rpcbind clients destruction on module cleanup
fs/nfsd/nfssvc.c | 2 +
include/linux/sunrpc/clnt.h | 2 +
include/linux/sunrpc/svc.h | 1
net/sunrpc/rpcb_clnt.c | 88 ++++++++++++++++++++++++++++---------------
net/sunrpc/sunrpc_syms.c | 3 -
net/sunrpc/svc.c | 57 ++++++++++++++++++++++++----
6 files changed, 113 insertions(+), 40 deletions(-)
^ permalink raw reply
* Re: >Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Linus Torvalds @ 2011-10-28 11:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ben Hutchings, Andi Kleen, linux-kernel, netdev, Andrew Morton
In-Reply-To: <1319777025.23112.67.camel@edumazet-laptop>
On Thu, Oct 27, 2011 at 9:43 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> The only requirement of atomic_read() is that it must return value
> before or after an atomic_write(), not a garbled value.
The problem is that gcc *can* return a garbled value.
> In fact, if a compiler is stupid enough to issue two reads on following
> code :
The compiler really *can* be that "stupid". Except the code tends to
look like this:
int value = atomic_read(&atomic_var);
if (value > 10)
return;
.. do something with value ..
and gcc may decide - under register pressure, and in the absense of a
'volatile' - to read 'value' first once for that "> 10" check, and
then it drops the registers and instead of saving it on the stack
frame, it can decide to re-load it from atomic_var.
IOW, "value" could be two or more different values: one value when
testing, and *another* value in "do something with value".
This is why we have "ACCESS_ONCE()".
Whether atomics guarantee ACCESS_ONCE() semantics or not is not
entirely clear. But afaik, there is no way to tell gcc "access at
*most* once, and never ever reload".
Linus
^ permalink raw reply
* Hello
From: lisa hedstrand @ 2011-10-28 11:24 UTC (permalink / raw)
My name is Miss Lisa Please accept my apology if my mode of contacting you will in any way offend you. I am compelled to contact you via this medium because i needed a friend from that part of the world. We will get to know each other in details if my proposition accepted. l am a student in UK but originally from USA.
^ permalink raw reply
* Re: [net-next PATCH] net: allow vlan traffic to be received under bond
From: Eric Dumazet @ 2011-10-28 11:06 UTC (permalink / raw)
To: David Miller
Cc: jesse, john.r.fastabend, hans.schillstrom, jpirko, mbizon, netdev,
fubar
In-Reply-To: <1319796053.23112.92.camel@edumazet-laptop>
Le vendredi 28 octobre 2011 à 12:00 +0200, Eric Dumazet a écrit :
> Oh well, this broke my setup, a very basic one.
>
> eth1 and eth2 on a bonding device, bond0, active-backup
>
> some vlans on top of bond0, say vlan.103
>
> $ ip link show dev vlan.103
> 8: vlan.103@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> pfifo_fast state UP qlen 100
> link/ether 00:1e:0b:ec:d3:d2 brd ff:ff:ff:ff:ff:ff
>
>
> arp_rcv() now gets packets with skb->type PACKET_OTHERHOST and drops
> such packets.
>
> [000] 52870.115435: skb_gro_reset_offset <-napi_gro_receive
> [000] 52870.115435: dev_gro_receive <-napi_gro_receive
> [000] 52870.115435: napi_skb_finish <-napi_gro_receive
> [000] 52870.115435: netif_receive_skb <-napi_skb_finish
> [000] 52870.115435: get_rps_cpu <-netif_receive_skb
> [000] 52870.115435: __netif_receive_skb <-netif_receive_skb
> [000] 52870.115436: vlan_do_receive <-__netif_receive_skb
> [000] 52870.115436: bond_handle_frame <-__netif_receive_skb
> [000] 52870.115436: vlan_do_receive <-__netif_receive_skb
> [000] 52870.115436: arp_rcv <-__netif_receive_skb
> [000] 52870.115436: kfree_skb <-arp_rcv
> [000] 52870.115437: __kfree_skb <-kfree_skb
> [000] 52870.115437: skb_release_head_state <-__kfree_skb
> [000] 52870.115437: skb_release_data <-__kfree_skb
> [000] 52870.115437: kfree <-skb_release_data
> [000] 52870.115437: kmem_cache_free <-__kfree_skb
>
>
> By the way, we have no SNMP counter here so I spent some time to track
> this. I'll send a patch for this.
>
> If this host initiates the trafic, all is well.
>
> Please guys, can we get back ARP or revert this patch ?
Following patch cures the problem, I am not sure its the right fix.
Problem is we dont know how many times vlan_do_receive() can be called
for a packet.
Only last call should set/mess pkt_type to PACKET_OTHERHOST.
So the caller should be responsible for this, not vlan_do_receive()
Alternative would be to check skb->dev->rx_handler being NULL,
but its not clean.
Following patch is a hack because it handles multicast/broadcast trafic
only. Unicast is already handled in lines 26-33, this is why we didnt
catch the problem.
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index f1f2f7b..6861899 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -13,7 +13,7 @@ bool vlan_do_receive(struct sk_buff **skbp)
vlan_dev = vlan_find_dev(skb->dev, vlan_id);
if (!vlan_dev) {
- if (vlan_id)
+ if (vlan_id && skb->pkt_type == PACKET_HOST)
skb->pkt_type = PACKET_OTHERHOST;
return false;
}
^ permalink raw reply related
* [PATCH v7 1/7] SUNRPC: introduce helpers for reference counted rpcbind clients
From: Stanislav Kinsbursky @ 2011-10-28 11:52 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem,
devel
In-Reply-To: <20111028104530.24628.23631.stgit@localhost6.localdomain6>
v6:
1) added write memory barrier to rpcb_set_local to make sure, that rpcbind
clients become valid before rpcb_users assignment
2) explicitly set rpcb_users to 1 instead of incrementing it (looks clearer from
my pow).
v5: fixed races with rpcb_users in rpcb_get_local()
This helpers will be used for dynamical creation and destruction of rpcbind
clients.
Variable rpcb_users is actually a counter of lauched RPC services. If rpcbind
clients has been created already, then we just increase rpcb_users.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/rpcb_clnt.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index e45d2fb..9830d87 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -114,6 +114,9 @@ static struct rpc_program rpcb_program;
static struct rpc_clnt * rpcb_local_clnt;
static struct rpc_clnt * rpcb_local_clnt4;
+DEFINE_SPINLOCK(rpcb_clnt_lock);
+unsigned int rpcb_users;
+
struct rpcbind_args {
struct rpc_xprt * r_xprt;
@@ -161,6 +164,56 @@ static void rpcb_map_release(void *data)
kfree(map);
}
+static int rpcb_get_local(void)
+{
+ int cnt;
+
+ spin_lock(&rpcb_clnt_lock);
+ if (rpcb_users)
+ rpcb_users++;
+ cnt = rpcb_users;
+ spin_unlock(&rpcb_clnt_lock);
+
+ return cnt;
+}
+
+void rpcb_put_local(void)
+{
+ struct rpc_clnt *clnt = rpcb_local_clnt;
+ struct rpc_clnt *clnt4 = rpcb_local_clnt4;
+ int shutdown;
+
+ spin_lock(&rpcb_clnt_lock);
+ if (--rpcb_users == 0) {
+ rpcb_local_clnt = NULL;
+ rpcb_local_clnt4 = NULL;
+ }
+ shutdown = !rpcb_users;
+ spin_unlock(&rpcb_clnt_lock);
+
+ if (shutdown) {
+ /*
+ * cleanup_rpcb_clnt - remove xprtsock's sysctls, unregister
+ */
+ if (clnt4)
+ rpc_shutdown_client(clnt4);
+ if (clnt)
+ rpc_shutdown_client(clnt);
+ }
+}
+
+static void rpcb_set_local(struct rpc_clnt *clnt, struct rpc_clnt *clnt4)
+{
+ /* Protected by rpcb_create_local_mutex */
+ rpcb_local_clnt = clnt;
+ rpcb_local_clnt4 = clnt4;
+ smp_wmb();
+ rpcb_users = 1;
+ dprintk("RPC: created new rpcb local clients (rpcb_local_clnt: "
+ "%p, rpcb_local_clnt4: %p)\n", rpcb_local_clnt,
+ rpcb_local_clnt4);
+}
+
/*
* Returns zero on success, otherwise a negative errno value
* is returned.
^ permalink raw reply related
* Re: [net-next PATCH] net: allow vlan traffic to be received under bond
From: Eric Dumazet @ 2011-10-28 10:00 UTC (permalink / raw)
To: David Miller
Cc: jesse, john.r.fastabend, hans.schillstrom, jpirko, mbizon, netdev,
fubar
In-Reply-To: <20111018.234723.1235424375699917420.davem@davemloft.net>
Le mardi 18 octobre 2011 à 23:47 -0400, David Miller a écrit :
> From: Jesse Gross <jesse@nicira.com>
> Date: Thu, 13 Oct 2011 17:22:02 -0700
>
> > Actually, for most of 2.6.x the behavior was somewhat
> > non-deterministic since it depended on kernel version and the NIC. As
> > a result, I think we can safely say that this wasn't a particularly
> > firm interface that we have to be wedded to. Based on overwhelming
> > feedback, I think the interface in this patch is the preferred one and
> > what we should stabilize on.
>
> Agreed, and I've applied this patch to net-next, thanks everyone!
Hmm.
Oh well, this broke my setup, a very basic one.
eth1 and eth2 on a bonding device, bond0, active-backup
some vlans on top of bond0, say vlan.103
$ ip link show dev vlan.103
8: vlan.103@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UP qlen 100
link/ether 00:1e:0b:ec:d3:d2 brd ff:ff:ff:ff:ff:ff
arp_rcv() now gets packets with skb->type PACKET_OTHERHOST and drops
such packets.
[000] 52870.115435: skb_gro_reset_offset <-napi_gro_receive
[000] 52870.115435: dev_gro_receive <-napi_gro_receive
[000] 52870.115435: napi_skb_finish <-napi_gro_receive
[000] 52870.115435: netif_receive_skb <-napi_skb_finish
[000] 52870.115435: get_rps_cpu <-netif_receive_skb
[000] 52870.115435: __netif_receive_skb <-netif_receive_skb
[000] 52870.115436: vlan_do_receive <-__netif_receive_skb
[000] 52870.115436: bond_handle_frame <-__netif_receive_skb
[000] 52870.115436: vlan_do_receive <-__netif_receive_skb
[000] 52870.115436: arp_rcv <-__netif_receive_skb
[000] 52870.115436: kfree_skb <-arp_rcv
[000] 52870.115437: __kfree_skb <-kfree_skb
[000] 52870.115437: skb_release_head_state <-__kfree_skb
[000] 52870.115437: skb_release_data <-__kfree_skb
[000] 52870.115437: kfree <-skb_release_data
[000] 52870.115437: kmem_cache_free <-__kfree_skb
By the way, we have no SNMP counter here so I spent some time to track
this. I'll send a patch for this.
If this host initiates the trafic, all is well.
Please guys, can we get back ARP or revert this patch ?
Thanks
^ permalink raw reply
* Re: [PATCH v6 5/8] SUNRPC: cleanup service destruction
From: Stanislav Kinsbursky @ 2011-10-28 9:49 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, davem@davemloft.net,
devel@openvz.org
In-Reply-To: <20111027213038.GD31669@fieldses.org>
28.10.2011 01:30, J. Bruce Fields пишет:
> On Tue, Oct 25, 2011 at 02:17:18PM +0300, Stanislav Kinsbursky wrote:
>> svc_unregister() call have to be removed from svc_destroy() since it will be
>> called in sv_shutdown callback.
>
> It would be clearer that you're *moving* this if this were merged with
> the following patch. And without doing that the series isn't quite
> bisectable, unless I'm missing something.
>
Yes, you are right. Will resend new version soon.
> --b.
>
>>
>> Signed-off-by: Stanislav Kinsbursky<skinsbursky@parallels.com>
>>
>> ---
>> net/sunrpc/svc.c | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
>> index 918edc3..407462f 100644
>> --- a/net/sunrpc/svc.c
>> +++ b/net/sunrpc/svc.c
>> @@ -530,7 +530,6 @@ svc_destroy(struct svc_serv *serv)
>> if (svc_serv_is_pooled(serv))
>> svc_pool_map_put();
>>
>> - svc_unregister(serv);
>> kfree(serv->sv_pools);
>> kfree(serv);
>> }
>>
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: [PATCH v3 0/3] SUNRPC: rcbind clients virtualization
From: Stanislav Kinsbursky @ 2011-10-28 9:41 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, davem@davemloft.net,
devel@openvz.org
In-Reply-To: <20111028093036.GA2604@fieldses.org>
28.10.2011 13:30, J. Bruce Fields пишет:
> On Fri, Oct 28, 2011 at 01:24:45PM +0400, Stanislav Kinsbursky wrote:
>> This patch-set was created before you've sent your NFSd plan and we
>> disacussed Lockd per netns.
>> So, this sentence: "NFSd service will be per netns too from my pow"
>> is obsolete. And Lockd will be one for all.
>
> I believe lockd should be pert-netns--at least that's what the server
> needs.
>
> (The single lockd thread may handle requests from all netns, but it
> should behave like a different service depending on netns, so its data
> structures, etc. will need to be per-ns.
>
Sure. Looks like we have misunderstanding here. When I said, that Lockd should
be one for all, I meaned, that we will have only one kthread for all ns (not one
per ns). Private data will be per net ns, of course.
BTW, Bruce, please, have a brief look at my e-mail to linux-nfs@vger.kernel.org
named "SUNRPC: non-exclusive pipe creation".
I've done a lot in "RPC pipefs per net ns" task, and going to send first patches
soon. But right now I'm really confused will this non-exclusive pipes creation
and almost ready so remove this functionality. But I'm afraid, that I've missed
something. Would be greatly appreciate for your opinion about my question.
> --b.
>
>> Or you are asking about something else?
>>
>>> --b.
>>>
>>>> And also we have NFSd file system, which
>>>> is not virtualized yet.
>>>>
>>>> The following series consists of:
>>>>
>>>> ---
>>>>
>>>> Stanislav Kinsbursky (3):
>>>> SUNRPC: move rpcbind internals to sunrpc part of network namespace context
>>>> SUNRPC: optimize net_ns dereferencing in rpcbind creation calls
>>>> SUNRPC: optimize net_ns dereferencing in rpcbind registering calls
>>>>
>>>>
>>>> net/sunrpc/netns.h | 5 ++
>>>> net/sunrpc/rpcb_clnt.c | 103 ++++++++++++++++++++++++++----------------------
>>>> 2 files changed, 61 insertions(+), 47 deletions(-)
>>>>
>>>> --
>>>> Signature
>>
>>
>> --
>> Best regards,
>> Stanislav Kinsbursky
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: [PATCH v3 0/3] SUNRPC: rcbind clients virtualization
From: J. Bruce Fields @ 2011-10-28 9:30 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, davem@davemloft.net,
devel@openvz.org
In-Reply-To: <4EAA74DD.3070708@parallels.com>
On Fri, Oct 28, 2011 at 01:24:45PM +0400, Stanislav Kinsbursky wrote:
> This patch-set was created before you've sent your NFSd plan and we
> disacussed Lockd per netns.
> So, this sentence: "NFSd service will be per netns too from my pow"
> is obsolete. And Lockd will be one for all.
I believe lockd should be pert-netns--at least that's what the server
needs.
(The single lockd thread may handle requests from all netns, but it
should behave like a different service depending on netns, so its data
structures, etc. will need to be per-ns.
--b.
> Or you are asking about something else?
>
> >--b.
> >
> >>And also we have NFSd file system, which
> >>is not virtualized yet.
> >>
> >>The following series consists of:
> >>
> >>---
> >>
> >>Stanislav Kinsbursky (3):
> >> SUNRPC: move rpcbind internals to sunrpc part of network namespace context
> >> SUNRPC: optimize net_ns dereferencing in rpcbind creation calls
> >> SUNRPC: optimize net_ns dereferencing in rpcbind registering calls
> >>
> >>
> >> net/sunrpc/netns.h | 5 ++
> >> net/sunrpc/rpcb_clnt.c | 103 ++++++++++++++++++++++++++----------------------
> >> 2 files changed, 61 insertions(+), 47 deletions(-)
> >>
> >>--
> >>Signature
>
>
> --
> Best regards,
> Stanislav Kinsbursky
^ permalink raw reply
* Re: [PATCH v6 4/8] SUNRPC: setup rpcbind clients if service requires it
From: Stanislav Kinsbursky @ 2011-10-28 9:27 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, davem@davemloft.net,
devel@openvz.org
In-Reply-To: <20111027212732.GC31669@fieldses.org>
28.10.2011 01:27, J. Bruce Fields пишет:
> On Tue, Oct 25, 2011 at 02:17:08PM +0300, Stanislav Kinsbursky wrote:
>> New function ("svc_uses_rpcbind") will be used to detect, that new service will
>> send portmapper register calls. For such services we will create rpcbind
>> clients and remove all stale portmap registrations.
>> Also, svc_rpcb_cleanup() will be set as sv_shutdown callback for such services
>> in case of this field wasn't initialized earlier. This will allow to destroy
>> rpcbind clients when no other users of them left.
>>
>> Note: Currently, any creating service will be detected as portmap user.
>> Probably, this is wrong. But now it depends on program versions "vs_hidden"
>> flag.
>>
>> Signed-off-by: Stanislav Kinsbursky<skinsbursky@parallels.com>
>>
>> ---
>> net/sunrpc/svc.c | 11 +++++++++--
>> 1 files changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
>> index d2d61bf..918edc3 100644
>> --- a/net/sunrpc/svc.c
>> +++ b/net/sunrpc/svc.c
>> @@ -454,8 +454,15 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>> spin_lock_init(&pool->sp_lock);
>> }
>>
>> - /* Remove any stale portmap registrations */
>> - svc_unregister(serv);
>> + if (svc_uses_rpcbind(serv)) {
>> + if (svc_rpcb_setup(serv)< 0) {
>> + kfree(serv->sv_pools);
>> + kfree(serv);
>> + return NULL;
>
> Nit: could we convert this (and the previous failure to allocate
> sv_pools) to the usual pattern of collecting the cleanup at the end and
> jumping to it with a goto?
>
Sure, we can. I will implement this "goto pattern", is you insist.
> Looks fine otherwise.
>
> --b.
>
>> + }
>> + if (!serv->sv_shutdown)
>> + serv->sv_shutdown = svc_rpcb_cleanup;
>> + }
>>
>> return serv;
>> }
>>
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: [PATCH v3 0/3] SUNRPC: rcbind clients virtualization
From: Stanislav Kinsbursky @ 2011-10-28 9:24 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, davem@davemloft.net,
devel@openvz.org
In-Reply-To: <20111027202514.GA31669@fieldses.org>
28.10.2011 00:25, J. Bruce Fields пишет:
> On Thu, Oct 27, 2011 at 10:10:43PM +0300, Stanislav Kinsbursky wrote:
>> v3:
>> 1) First two patches from previous version were squashed.
>>
>> This patch-set was created in context of clone of git branch:
>> git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git
>> and rebased on tag "v3.1".
>>
>> This patch-set virtualizes rpcbind clients per network namespace context. IOW,
>> each network namespace will have its own pair of rpcbind clients (if they would
>> be created by request).
>>
>> Note:
>> 1) this patch-set depends on "SUNRPC: make rpcbind clients allocated and
>> destroyed dynamically" patch-set which has been send earlier.
>> 2) init_net pointer is still used instead of current->nsproxy->net_ns,
>> because I'm not sure yet about how to virtualize services. I.e. NFS callback
>> services will be per netns. NFSd service will be per netns too from my pow. But
>> Lockd can be per netns or one for all.
>
> I'm not sure what you mean by that; could you explain?
>
This patch-set was created before you've sent your NFSd plan and we disacussed
Lockd per netns.
So, this sentence: "NFSd service will be per netns too from my pow" is obsolete.
And Lockd will be one for all.
Or you are asking about something else?
> --b.
>
>> And also we have NFSd file system, which
>> is not virtualized yet.
>>
>> The following series consists of:
>>
>> ---
>>
>> Stanislav Kinsbursky (3):
>> SUNRPC: move rpcbind internals to sunrpc part of network namespace context
>> SUNRPC: optimize net_ns dereferencing in rpcbind creation calls
>> SUNRPC: optimize net_ns dereferencing in rpcbind registering calls
>>
>>
>> net/sunrpc/netns.h | 5 ++
>> net/sunrpc/rpcb_clnt.c | 103 ++++++++++++++++++++++++++----------------------
>> 2 files changed, 61 insertions(+), 47 deletions(-)
>>
>> --
>> Signature
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: [RFC] tcp: Export TCP Delayed ACK parameters to user
From: Eric Dumazet @ 2011-10-28 8:44 UTC (permalink / raw)
To: Daniel Baluta; +Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <CAEnQRZAj4H9neNsGB8hkrQO5trvP8QimhKhpnwchjTVrAo2LGQ@mail.gmail.com>
Le vendredi 28 octobre 2011 à 11:01 +0300, Daniel Baluta a écrit :
> On Fri, Oct 28, 2011 at 3:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le vendredi 28 octobre 2011 à 02:07 +0300, Daniel Baluta a écrit :
> >> RFC2581 ($4.2) specifies when an ACK should be generated as follows:
> >>
> >> " .. an ACK SHOULD be generated for at least every second
> >> full-sized segment, and MUST be generated within 500 ms
> >> of the arrival of the first unacknowledged packet.
> >> "
> >>
> >> We export the number of segments and the timeout limits
> >> specified above, so that a user can tune them according
> >> to its needs.
> >>
> >
> > Well, this requires user has a machine exclusive use :)
>
> So, this means that setting parameters system wide
> isn't an option?
>
It is a first step, but we can notice a global setting might please one
application but negatively impact other applications.
I guess some users will want a per socket option, but this can come
later. An other idea to save space on socket structures would be to
select two set of values depending on TOS/TCLASS.
I can imagine ssh (lowdelay) and scp (throughput) wanting different
behavior here.
> On Windows there is a global setting TcpAckFrequency [1],
> which is similar with our tcp_delack_{min,max}.
>
> On Solaris there is a global option tcp_deferred_acks_max [2],
> which is similar with our tcp_delack_segs.
>
and also has tcp_deferred_ack_interval
> Thanks for your comments, I will post an updated patch asap.
>
> Daniel.
>
> [1] http://support.microsoft.com/kb/328890
> [2] http://www.sean.de/Solaris/soltune.html
Dont forget to CC Andy Lutomirski <luto@amacapital.net>, he might be
interested being part of the process.
Thanks
^ permalink raw reply
* Re: [RFC] tcp: Export TCP Delayed ACK parameters to user
From: Daniel Baluta @ 2011-10-28 8:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1319760097.19125.55.camel@edumazet-laptop>
On Fri, Oct 28, 2011 at 3:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 28 octobre 2011 à 02:07 +0300, Daniel Baluta a écrit :
>> RFC2581 ($4.2) specifies when an ACK should be generated as follows:
>>
>> " .. an ACK SHOULD be generated for at least every second
>> full-sized segment, and MUST be generated within 500 ms
>> of the arrival of the first unacknowledged packet.
>> "
>>
>> We export the number of segments and the timeout limits
>> specified above, so that a user can tune them according
>> to its needs.
>>
>
> Well, this requires user has a machine exclusive use :)
So, this means that setting parameters system wide
isn't an option?
On Windows there is a global setting TcpAckFrequency [1],
which is similar with our tcp_delack_{min,max}.
On Solaris there is a global option tcp_deferred_acks_max [2],
which is similar with our tcp_delack_segs.
Thanks for your comments, I will post an updated patch asap.
Daniel.
[1] http://support.microsoft.com/kb/328890
[2] http://www.sean.de/Solaris/soltune.html
^ permalink raw reply
* >Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Eric Dumazet @ 2011-10-28 4:43 UTC (permalink / raw)
To: Ben Hutchings
Cc: Linus Torvalds, Andi Kleen, linux-kernel, netdev, Andrew Morton
In-Reply-To: <1319772566.6759.27.camel@deadeye>
Le vendredi 28 octobre 2011 à 04:29 +0100, Ben Hutchings a écrit :
> On Fri, 2011-10-28 at 04:52 +0200, Eric Dumazet wrote:
> > Le vendredi 28 octobre 2011 à 02:44 +0100, Ben Hutchings a écrit :
> >
> > > Whether or not it needs to provide any ordering guarantee, atomic_read()
> > > must never read more than once, and I think that requires the volatile
> > > qualification. It might be clearer to use the ACCESS_ONCE macro,
> > > however.
> > >
> >
> > Where this requirement comes from ?
>
> That is the conventional behaviour of 'atomic' operations, and callers
> may depend on it.
>
Thats your opinion, not a fact documented in
Documentation/atomic_ops.txt
<QUOTE>
---------------------------------------------------------
Next, we have:
#define atomic_read(v) ((v)->counter)
which simply reads the counter value currently visible to the calling thread.
The read is atomic in that the return value is guaranteed to be one of the
values initialized or modified with the interface operations if a proper
implicit or explicit memory barrier is used after possible runtime
initialization by any other thread and the value is modified only with the
interface operations. atomic_read does not guarantee that the runtime
initialization by any other thread is visible yet, so the user of the
interface must take care of that with a proper implicit or explicit memory
barrier.
*** WARNING: atomic_read() and atomic_set() DO NOT IMPLY BARRIERS! ***
Some architectures may choose to use the volatile keyword, barriers, or inline
assembly to guarantee some degree of immediacy for atomic_read() and
atomic_set(). This is not uniformly guaranteed, and may change in the future,
so all users of atomic_t should treat atomic_read() and atomic_set() as simple
C statements that may be reordered or optimized away entirely by the compiler
or processor, and explicitly invoke the appropriate compiler and/or memory
barrier for each use case. Failure to do so will result in code that may
suddenly break when used with different architectures or compiler
optimizations, or even changes in unrelated code which changes how the
compiler optimizes the section accessing atomic_t variables.
*** YOU HAVE BEEN WARNED! ***
---------------------------------------------------------------
</QUOTE>
The only requirement of atomic_read() is that it must return value
before or after an atomic_write(), not a garbled value.
So the ACCESS_ONCE semantic is on the write side (the atomic itself
cannot be used as a temporary variable. It must contain only two value
of atomic_{write|add|sub}() [ prior to the operation, after the
operation ]
In fact, if a compiler is stupid enough to issue two reads on following
code :
static inline atomic_read(const atomic_t *p)
{
return p->value;
}
Then its fine, because in the end the returned value will be the old or
new one.
^ permalink raw reply
* Re: [PATCH] ipv6: fix error propagation in ip6_ufo_append_data()
From: David Miller @ 2011-10-28 4:26 UTC (permalink / raw)
To: zheng.z.yan; +Cc: netdev
In-Reply-To: <4EAA2E74.2000703@intel.com>
From: "Yan, Zheng" <zheng.z.yan@intel.com>
Date: Fri, 28 Oct 2011 12:24:20 +0800
> We should return errcode from sock_alloc_send_skb()
>
> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
Applied, thanks!
^ permalink raw reply
* [PATCH] ipv6: fix error propagation in ip6_ufo_append_data()
From: Yan, Zheng @ 2011-10-28 4:24 UTC (permalink / raw)
To: netdev@vger.kernel.org, davem@davemloft.net
We should return errcode from sock_alloc_send_skb()
Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
---
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index ff30047..84d0bd5 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1123,7 +1123,7 @@ static inline int ip6_ufo_append_data(struct sock *sk,
hh_len + fragheaderlen + transhdrlen + 20,
(flags & MSG_DONTWAIT), &err);
if (skb == NULL)
- return -ENOMEM;
+ return err;
/* reserve space for Hardware header */
skb_reserve(skb, hh_len);
^ permalink raw reply related
* Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Ben Hutchings @ 2011-10-28 3:29 UTC (permalink / raw)
To: Eric Dumazet
Cc: Linus Torvalds, Andi Kleen, linux-kernel, netdev, Andrew Morton
In-Reply-To: <1319770376.23112.58.camel@edumazet-laptop>
On Fri, 2011-10-28 at 04:52 +0200, Eric Dumazet wrote:
> Le vendredi 28 octobre 2011 à 02:44 +0100, Ben Hutchings a écrit :
>
> > Whether or not it needs to provide any ordering guarantee, atomic_read()
> > must never read more than once, and I think that requires the volatile
> > qualification. It might be clearer to use the ACCESS_ONCE macro,
> > however.
> >
>
> Where this requirement comes from ?
That is the conventional behaviour of 'atomic' operations, and callers
may depend on it.
> Maybe then introduce atomic_read_once() for users really needing it :)
>
> ACCESS_ONCE will force the read/move instruction I try to avoid :(
[...]
I'm sure you can find some other way to avoid it.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
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
* Re: [PATCH 1/3] stmmac: fix a bug while checking the HW cap reg (v2)
From: David Miller @ 2011-10-28 3:17 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1319694189-25223-1-git-send-email-peppe.cavallaro@st.com>
All 3 patches applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6 0/2] be2net: fixes
From: David Miller @ 2011-10-28 3:17 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev
In-Reply-To: <900362ce-e840-44cb-bfcf-72eba609edf3@exht2.ad.emulex.com>
From: Somnath Kotur <somnath.kotur@Emulex.Com>
Date: Thu, 27 Oct 2011 22:41:47 +0530
> Somnath Kotur (2):
> be2net: Refactored be_cmds.c file.
> be2net: Changing MAC Address of a VF (in SR-IOV case) was broken.
Applied.
^ permalink raw reply
* Re: [PATCH net -v2] [BUGFIX] bonding: use flush_delayed_work_sync in bond_close
From: David Miller @ 2011-10-28 3:15 UTC (permalink / raw)
To: mitsuo.hayasaka.hu
Cc: fubar, netdev, xiyou.wangcong, shemminger, andy, linux-kernel,
yrl.pp-manager.tt
In-Reply-To: <4EAA0ADF.5020504@hitachi.com>
From: HAYASAKA Mitsuo <mitsuo.hayasaka.hu@hitachi.com>
Date: Fri, 28 Oct 2011 10:52:31 +0900
> I checked your patch, and any problems have not been observed for
> almost one day although I could reproduce the BUG in the latest net-next
> without it.
>
> I think this patch works well.
>
> Tested-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
Jay, please formally submit this patch with proper signoffs etc.
Thanks!
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove quotes of maintaners's names
From: David Miller @ 2011-10-28 3:01 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: marcos.mage, akpm, netdev, linux-kernel
In-Reply-To: <610B86C6-622E-4EFE-89DF-BF09BDB4D765@intel.com>
From: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>
Date: Thu, 27 Oct 2011 14:35:54 -0700
> The reason these names are in quotes is because they need to be
> wrapped in quotes when used in a git patch (I.e. CC: "David
> S. Miller" <davem@davemloft.net>) because of the . in the friendly
> name.
That's correct, if a character such as "." appears in an email
header field it must be surrounded by double quotes, as per
SMTP rules.
VGER rejects any email where this rule is not followed properly.
^ permalink raw reply
* Re: [patch net-next]alx: Atheros AR8131/AR8151/AR8152/AR8161 Ethernet driver
From: Joe Perches @ 2011-10-28 2:56 UTC (permalink / raw)
To: Francois Romieu; +Cc: cloud.ren, davem, Luis.Rodriguez, netdev, linux-kernel
In-Reply-To: <20111019222140.GA9937@electric-eye.fr.zoreil.com>
On Thu, 2011-10-20 at 00:21 +0200, Francois Romieu wrote:
> cloud.ren@atheros.com <cloud.ren@atheros.com> :
> > diff --git a/drivers/net/ethernet/atheros/alx/alf_hw.c b/drivers/net/ethernet/atheros/alx/alf_hw.c
[]
> > + if (en) { /* enable */
> > + MEM_W32(ctx, L1F_RXQ0, rxq | L1F_RXQ0_EN);
> > + MEM_W32(ctx, L1F_TXQ0, txq | L1F_TXQ0_EN);
> > + if (0 != (en_ctrl & LX_MACSPEED_1000)) {
> > + FIELD_SETL(mac, L1F_MAC_CTRL_SPEED,
> > + L1F_MAC_CTRL_SPEED_1000);
> > + } else {
> > + FIELD_SETL(mac, L1F_MAC_CTRL_SPEED,
> > + L1F_MAC_CTRL_SPEED_10_100);
> > + }
> > + if (0 != (en_ctrl & LX_MACDUPLEX_FULL)) {
> > + mac |= L1F_MAC_CTRL_FULLD;
> > + } else {
> > + mac &= ~L1F_MAC_CTRL_FULLD;
> > + }
> > + /* rx filter */
> > + if (0 != (en_ctrl & LX_FLT_PROMISC)) {
> > + mac |= L1F_MAC_CTRL_PROMISC_EN;
> > + } else {
> > + mac &= ~L1F_MAC_CTRL_PROMISC_EN;
> > + }
> > + if (0 != (en_ctrl & LX_FLT_MULTI_ALL)) {
> > + mac |= L1F_MAC_CTRL_MULTIALL_EN;
> > + } else {
> > + mac &= ~L1F_MAC_CTRL_MULTIALL_EN;
> > + }
> > + if (0 != (en_ctrl & LX_FLT_BROADCAST)) {
> > + mac |= L1F_MAC_CTRL_BRD_EN;
> > + } else {
> > + mac &= ~L1F_MAC_CTRL_BRD_EN;
> > + }
> Code duplication. Who cares ?
Maybe add a macro like:
#define mac_ctrl(mac, ctrl, flag, bit) \
do { \
if ((ctrl) & (flag)) \
mac |= (bit); \
else \
mac &= ~(bit); \
} while (0)
so these become
mac_ctrl(mac, en_ctrl, LX_MACDUPLEX_FULL, L1F_MAC_CTRL_FULLD);
mac_ctrl(mac, en_ctrl, LX_FLT_PROMISC, L1F_MAC_CTRL_PROMISC_EN);
mac_ctrl(mac, en_ctrl, LX_FLT_MULTI_ALL, L1F_MAC_CTRL_MULTIALL_EN);
mac_ctrl(mac, en_ctrl, LX_FLT_BROADCAST, L1F_MAC_CTRL_BRD_EN);
mac_ctrl(mac, en_ctrl, LX_FLT_DIRECT, L1F_MAC_CTRL_RX_EN);
mac_ctrl(mac, en_ctrl, LX_FC_TXEN, L1F_MAC_CTRL_TXFC_EN);
mac_ctrl(mac, en_ctrl, LX_FC_RXEN, L1F_MAC_CTRL_RXFC_EN);
etc.
Or maybe add mac, en_ctrl and L1F_MAC_CTRL_ to the macro if you
really want to shorten it up.
mac_ctrl(MACDUPLEX_FULL, FULLD);
mac_ctrl(FLT_PROMISC, PROMISC_EN);
mac_ctrl(FLT_MULTI_ALL, MULTIALL_EN);
etc.
> It may make some sense to move these ~60 loc in a xyz_enable_something
> method...
2 macros?
^ permalink raw reply
* Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Eric Dumazet @ 2011-10-28 2:52 UTC (permalink / raw)
To: Ben Hutchings
Cc: Linus Torvalds, Andi Kleen, linux-kernel, netdev, Andrew Morton
In-Reply-To: <1319766293.6759.17.camel@deadeye>
Le vendredi 28 octobre 2011 à 02:44 +0100, Ben Hutchings a écrit :
> Whether or not it needs to provide any ordering guarantee, atomic_read()
> must never read more than once, and I think that requires the volatile
> qualification. It might be clearer to use the ACCESS_ONCE macro,
> however.
>
Where this requirement comes from ?
Maybe then introduce atomic_read_once() for users really needing it :)
ACCESS_ONCE will force the read/move instruction I try to avoid :(
By the way, removing volatile on my x86_64 defconfig saves a bit of
space :
# size vmlinux vmlinux.old
text data bss dec hex filename
10907585 2890992 1540096 15338673 ea0cb1 vmlinux
10912342 2891056 1540096 15343494 ea1f86 vmlinux.old
booted and everything seems fine, but obviously lightly tested...
Note : There is still one useless access to page-flags,
'fixing' atomic_read() is not enough.
0,04 : ffffffff815e4675: je ffffffff815e4870 <tcp_sendmsg+0xc80>
0,08 : ffffffff815e467b: mov (%r9),%rax // useless
2,08 : ffffffff815e467e: lock incl 0x1c(%r9)
3,58 : ffffffff815e4683: mov (%r9),%rax
0,04 : ffffffff815e4686: test $0x80,%ah
0,00 : ffffffff815e4689: jne ffffffff815e48ee <tcp_sendmsg+0xcfe>
^ permalink raw reply
* Re: Introduce FCLONE_SCRATCH skbs to reduce stack memory useage and napi jitter
From: Eric Dumazet @ 2011-10-28 2:37 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, David S. Miller
In-Reply-To: <20111028013729.GA6524@neilslaptop.think-freely.org>
Le jeudi 27 octobre 2011 à 21:37 -0400, Neil Horman a écrit :
> >
> Yes, I'd experimented with some of this, and had mixed results. Specifically I
> came up with a way to use the additional space as an array of list heads, with
> backpointers to the socket_queue each list_head was owned by and the skb that
> owned the entry. It was nice because it let me enqueue the same skb to hundreds
> of sockets at the same time, which was really nice. It was bad however, because
> it completely broke socket accounting (any likely anything else that required on
> any part of the socket state). Any thoughts on ways I might improve on that.
> If I could make some sort of reduced sk_buff so that I didn't have to allocate
> all 256 bytes of a full sk_buff, that would be great!
It seems your objectives are contradictory (memory saving and cpu
saving). Most of the time we have to fight false sharing first.
I dont want to try to use the available space from skb, since its cache
unfriendly, in case you have one CPU 100% in softirq handling,
dispatching messages to XX other application cpus.
You dont want each application cpu slowing down other cpus by
manipulating a list anchor, contained in a shared cache line, highly
contended. We already have one high contention point (skb refcount or
data refcount).
Another point of interest is that modern NIC tend to use paged frag
skbs, with very litle space available in skb head. frag part is
readonly, and sometime with no available space neither.
So your idea only works on some (old gen) nics and some narrow
conditions.
I believe it adds too much complex code for this.
I understand you are disappointed, but maybe you should have shared your
ideas before coding them !
^ 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