* [RFC PATCH 2/5] SUNRPC: send notification events on pipefs sb creation and destruction
From: Stanislav Kinsbursky @ 2011-10-17 13:10 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem,
devel
In-Reply-To: <20111017120629.4541.67395.stgit@localhost6.localdomain6>
It will be used to notify subscribers about pipefs superblock creation and
destruction.
Cubcriders have to create their dentries on passed superblock on mount event
and destroy otherwise.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
include/linux/sunrpc/rpc_pipe_fs.h | 8 ++++++++
net/sunrpc/rpc_pipe.c | 27 +++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/include/linux/sunrpc/rpc_pipe_fs.h b/include/linux/sunrpc/rpc_pipe_fs.h
index cf14db9..c1cdb2f 100644
--- a/include/linux/sunrpc/rpc_pipe_fs.h
+++ b/include/linux/sunrpc/rpc_pipe_fs.h
@@ -44,6 +44,14 @@ RPC_I(struct inode *inode)
return container_of(inode, struct rpc_inode, vfs_inode);
}
+extern int rpc_pipefs_notifier_register(struct notifier_block *);
+extern void rpc_pipefs_notifier_unregister(struct notifier_block *);
+
+enum {
+ RPC_PIPEFS_MOUNT,
+ RPC_PIPEFS_UMOUNT,
+};
+
extern int rpc_queue_upcall(struct inode *, struct rpc_pipe_msg *);
struct rpc_clnt;
diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index 8322080..c90a7e0 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -28,6 +28,7 @@
#include <linux/sunrpc/rpc_pipe_fs.h>
#include <linux/sunrpc/cache.h>
#include <linux/nsproxy.h>
+#include <linux/notifier.h>
#include "netns.h"
@@ -41,6 +42,18 @@ static struct kmem_cache *rpc_inode_cachep __read_mostly;
#define RPC_UPCALL_TIMEOUT (30*HZ)
+static BLOCKING_NOTIFIER_HEAD(rpc_pipefs_notifier_list);
+
+int rpc_pipefs_notifier_register(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_cond_register(&rpc_pipefs_notifier_list, nb);
+}
+
+void rpc_pipefs_notifier_unregister(struct notifier_block *nb)
+{
+ blocking_notifier_chain_unregister(&rpc_pipefs_notifier_list, nb);
+}
+
static void rpc_purge_list(struct rpc_inode *rpci, struct list_head *head,
void (*destroy_msg)(struct rpc_pipe_msg *), int err)
{
@@ -1010,6 +1023,7 @@ rpc_fill_super(struct super_block *sb, void *data, int silent)
struct inode *inode;
struct dentry *root;
struct net *net = current->nsproxy->net_ns;
+ int err;
sb->s_blocksize = PAGE_CACHE_SIZE;
sb->s_blocksize_bits = PAGE_CACHE_SHIFT;
@@ -1027,8 +1041,18 @@ rpc_fill_super(struct super_block *sb, void *data, int silent)
}
if (rpc_populate(root, files, RPCAUTH_lockd, RPCAUTH_RootEOF, NULL))
return -ENOMEM;
+ err = blocking_notifier_call_chain(&rpc_pipefs_notifier_list,
+ RPC_PIPEFS_MOUNT,
+ sb);
+ if (err)
+ goto err_depopulate;
sb->s_fs_info = get_net(net);
return 0;
+
+err_depopulate:
+ /* TODO: check if we need to send RPC_PIPEFS_UMOUNT notification. */
+ __rpc_depopulate(root, files, RPCAUTH_lockd, RPCAUTH_RootEOF);
+ return err;
}
static struct dentry *
@@ -1043,6 +1067,9 @@ void rpc_kill_sb(struct super_block *sb)
struct net *net = sb->s_fs_info;
put_net(net);
+ blocking_notifier_call_chain(&rpc_pipefs_notifier_list,
+ RPC_PIPEFS_UMOUNT,
+ sb);
kill_litter_super(sb);
}
^ permalink raw reply related
* [RFC PATCH 3/5] SUNRPC: pipefs dentry lookup helper introduced
From: Stanislav Kinsbursky @ 2011-10-17 13:10 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem,
devel
In-Reply-To: <20111017120629.4541.67395.stgit@localhost6.localdomain6>
In all places, where pipefs dentries are created, only directory inode is
actually required to create new dentry. And all this directories has root
pipefs dentry as their parent. So we actually don't need this pipefs mount
point at all if some pipefs lookup method will be provided.
IOW, all we really need is just superblock and simple lookup method to find
root's dentry child dentry with appropriate name. And this patch introduces
this method.
Note, that no loking implemented in rpc_d_lookup_sb(). So it can be used only
in case of assurance, that pipefs superblock still exist. IOW, we can use this
method only in pipefs mount-umount notificators.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
include/linux/sunrpc/rpc_pipe_fs.h | 3 +++
net/sunrpc/rpc_pipe.c | 16 ++++++++++++++++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/include/linux/sunrpc/rpc_pipe_fs.h b/include/linux/sunrpc/rpc_pipe_fs.h
index c1cdb2f..4a327ad 100644
--- a/include/linux/sunrpc/rpc_pipe_fs.h
+++ b/include/linux/sunrpc/rpc_pipe_fs.h
@@ -52,6 +52,9 @@ enum {
RPC_PIPEFS_UMOUNT,
};
+extern struct dentry *rpc_d_lookup_sb(const struct super_block *sb,
+ const unsigned char *dir_name);
+
extern int rpc_queue_upcall(struct inode *, struct rpc_pipe_msg *);
struct rpc_clnt;
diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index c90a7e0..a8a8812 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -1017,6 +1017,22 @@ static const struct rpc_filelist files[] = {
},
};
+/*
+ * This call can be used only in RPC pipefs mount notification hooks.
+ */
+struct dentry *rpc_d_lookup_sb(const struct super_block *sb,
+ const unsigned char *dir_name)
+{
+ struct qstr dir = {
+ .name = dir_name,
+ .len = strlen(dir_name),
+ .hash = full_name_hash(dir_name, strlen(dir_name)),
+ };
+
+ return d_lookup(sb->s_root, &dir);
+}
+EXPORT_SYMBOL_GPL(rpc_d_lookup_sb);
+
static int
rpc_fill_super(struct super_block *sb, void *data, int silent)
{
^ permalink raw reply related
* [RFC PATCH 4/5] SUNRPC: put pipefs superblock link on network namespace
From: Stanislav Kinsbursky @ 2011-10-17 13:10 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem,
devel
In-Reply-To: <20111017120629.4541.67395.stgit@localhost6.localdomain6>
We have modules (like, pNFS blocklayout module) which creates pipes on
rpc_pipefs. Thus we need per-net operations for them. To make it possible to
create piepes in per-net operations, we require super block. So we have to put
sb link on network namespace context. Note, that dont't hardly require to
create pipes in per-net operations. IOW, if pipefs wan't mounted yet, that no
sb link reference will peresent on network namespace. In this case we just
passing through pipe
creation. The pipe will be created druing pipefs mount notification.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/netns.h | 2 ++
net/sunrpc/rpc_pipe.c | 4 ++++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/sunrpc/netns.h b/net/sunrpc/netns.h
index d013bf2..b384252 100644
--- a/net/sunrpc/netns.h
+++ b/net/sunrpc/netns.h
@@ -9,6 +9,8 @@ struct cache_detail;
struct sunrpc_net {
struct proc_dir_entry *proc_net_rpc;
struct cache_detail *ip_map_cache;
+
+ struct super_block *pipefs_sb;
};
extern int sunrpc_net_id;
diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index a8a8812..a873f03 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -1039,6 +1039,7 @@ rpc_fill_super(struct super_block *sb, void *data, int silent)
struct inode *inode;
struct dentry *root;
struct net *net = current->nsproxy->net_ns;
+ struct sunrpc_net *sn = net_generic(net, sunrpc_net_id);
int err;
sb->s_blocksize = PAGE_CACHE_SIZE;
@@ -1063,6 +1064,7 @@ rpc_fill_super(struct super_block *sb, void *data, int silent)
if (err)
goto err_depopulate;
sb->s_fs_info = get_net(net);
+ sn->pipefs_sb = sb;
return 0;
err_depopulate:
@@ -1081,7 +1083,9 @@ rpc_mount(struct file_system_type *fs_type,
void rpc_kill_sb(struct super_block *sb)
{
struct net *net = sb->s_fs_info;
+ struct sunrpc_net *sn = net_generic(net, sunrpc_net_id);
+ sn->pipefs_sb = NULL;
put_net(net);
blocking_notifier_call_chain(&rpc_pipefs_notifier_list,
RPC_PIPEFS_UMOUNT,
^ permalink raw reply related
* [RFC PATCH 5/5] SUNRPC: pipefs per-net operations helper introduced
From: Stanislav Kinsbursky @ 2011-10-17 13:10 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem,
devel
In-Reply-To: <20111017120629.4541.67395.stgit@localhost6.localdomain6>
During per-net operation pipes creation and destruction we have to make sure,
that pipefs sb exists for the whole creation/destruction procedure.
This is done by using special mutex which controls pipefs sb reference on network namespace context.
Helper consist of two parts: first of them (rpc_get_dentry_net) searches for
dentry with specified name and returns with mutex taken on success. When pipe
creation is completed, caller should release this mutex by rpc_put_dentry_net
call.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
include/linux/sunrpc/rpc_pipe_fs.h | 5 ++++
net/sunrpc/netns.h | 1 +
net/sunrpc/rpc_pipe.c | 41 ++++++++++++++++++++++++++++++++++++
net/sunrpc/sunrpc_syms.c | 1 +
4 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/include/linux/sunrpc/rpc_pipe_fs.h b/include/linux/sunrpc/rpc_pipe_fs.h
index 4a327ad..d48ff0b 100644
--- a/include/linux/sunrpc/rpc_pipe_fs.h
+++ b/include/linux/sunrpc/rpc_pipe_fs.h
@@ -55,6 +55,11 @@ enum {
extern struct dentry *rpc_d_lookup_sb(const struct super_block *sb,
const unsigned char *dir_name);
+extern void rpc_pipefs_init_net(struct net *net);
+extern struct dentry *rpc_get_dentry_net(const struct net *net,
+ const unsigned char *dir_name);
+extern void rpc_put_dentry_net(const struct net *net, struct dentry *dentry);
+
extern int rpc_queue_upcall(struct inode *, struct rpc_pipe_msg *);
struct rpc_clnt;
diff --git a/net/sunrpc/netns.h b/net/sunrpc/netns.h
index b384252..11d2f48 100644
--- a/net/sunrpc/netns.h
+++ b/net/sunrpc/netns.h
@@ -11,6 +11,7 @@ struct sunrpc_net {
struct cache_detail *ip_map_cache;
struct super_block *pipefs_sb;
+ struct mutex pipefs_sb_lock;
};
extern int sunrpc_net_id;
diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index a873f03..331be28 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -1033,6 +1033,45 @@ struct dentry *rpc_d_lookup_sb(const struct super_block *sb,
}
EXPORT_SYMBOL_GPL(rpc_d_lookup_sb);
+void rpc_pipefs_init_net(struct net *net)
+{
+ struct sunrpc_net *sn = net_generic(net, sunrpc_net_id);
+
+ mutex_init(&sn->pipefs_sb_lock);
+}
+
+/*
+ * This call will be used for per network namespace operations calls.
+ * Note: Function will be returned with pipefs_sb_lock taken if dentry was
+ * found. This lock have to be released by rpc_put_dentry_net() when all
+ * operations will be completed.
+ */
+struct dentry *rpc_get_dentry_net(const struct net *net,
+ const unsigned char *dir_name)
+{
+ struct sunrpc_net *sn = net_generic(net, sunrpc_net_id);
+ struct dentry *dentry = ERR_PTR(-ENOENT);
+
+ mutex_lock(&sn->pipefs_sb_lock);
+ if (sn->pipefs_sb) {
+ dentry = rpc_d_lookup_sb(sn->pipefs_sb, dir_name);
+ if (dentry)
+ return dentry;
+ }
+ mutex_unlock(&sn->pipefs_sb_lock);
+ return ERR_PTR(-ENOENT);
+}
+EXPORT_SYMBOL_GPL(rpc_get_dentry_net);
+
+void rpc_put_dentry_net(const struct net *net, struct dentry *dentry)
+{
+ struct sunrpc_net *sn = net_generic(net, sunrpc_net_id);
+
+ dput(dentry);
+ mutex_unlock(&sn->pipefs_sb_lock);
+}
+EXPORT_SYMBOL_GPL(rpc_put_dentry_net);
+
static int
rpc_fill_super(struct super_block *sb, void *data, int silent)
{
@@ -1085,7 +1124,9 @@ void rpc_kill_sb(struct super_block *sb)
struct net *net = sb->s_fs_info;
struct sunrpc_net *sn = net_generic(net, sunrpc_net_id);
+ mutex_lock(&sn->pipefs_sb_lock);
sn->pipefs_sb = NULL;
+ mutex_unlock(&sn->pipefs_sb_lock);
put_net(net);
blocking_notifier_call_chain(&rpc_pipefs_notifier_list,
RPC_PIPEFS_UMOUNT,
diff --git a/net/sunrpc/sunrpc_syms.c b/net/sunrpc/sunrpc_syms.c
index 9d08091..880de8b 100644
--- a/net/sunrpc/sunrpc_syms.c
+++ b/net/sunrpc/sunrpc_syms.c
@@ -38,6 +38,7 @@ static __net_init int sunrpc_init_net(struct net *net)
if (err)
goto err_ipmap;
+ rpc_pipefs_init_net(net);
return 0;
err_ipmap:
^ permalink raw reply related
* RE: [PATCH] smsc911x: Add regulator support
From: Robert MARKLUND @ 2011-10-17 14:13 UTC (permalink / raw)
To: Mark Brown; +Cc: netdev@vger.kernel.org, Steve Glendinning, Mathieu Poirer
In-Reply-To: <20111017123614.GC27266@opensource.wolfsonmicro.com>
> -----Original Message-----
> From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com]
> Sent: den 17 oktober 2011 14:36
> To: Robert MARKLUND
> Cc: netdev@vger.kernel.org; Steve Glendinning; Mathieu Poirer
> Subject: Re: [PATCH] smsc911x: Add regulator support
>
> On Mon, Oct 17, 2011 at 01:30:06PM +0200, Robert MARKLUND wrote:
>
> You should fix your mail client to word wrap within paragraphs, I've
> reformatted it for legibility. Also leave a blank line between
> paragraphs for the same reason.
I have tried but it's not as easy as it sounds :)
Does it look better now ?
>
> > > No, this is broken - look at how other devices use the regulator API.
> > > The driver should just request and use the regulators unconditionally
> > > and let the stubbing and mapping facilities the API has deal with
> > > ensuring that they always succeed.
>
> > So what you mean is get them and use them and ignore all the return
> > codes, and let the FW take care of the error handling ?
>
> No, you should do what all the other drivers do and actually pay
> attention to the errors. If we can't get power to the device that's a
> pretty serious problem and the driver ought to fail.
Then I don't understand the initial comment.
Can you please elaborate that one.
>
> > > As a side note the use of "pdata" as a name for the driver internal data
> > > is really not helpful, pdata is traditionally the platform data passed
> > > in by the machine (which would be even more broken).
>
> > In the driver they have used this name for this structure throughout
> > the file I just followed that. Personally I think it will be more
> > confusing to change the name of this structure in just this new
> > function.
>
> I think someone should send a patch renaming the data throughout the
> entire driver, it's a terrible name for an embedded context.
I agree let this someone do it.
In the meanwhile isn't it best to keep the style that in the driver as of now.
/R
^ permalink raw reply
* Re: [PATCH] smsc911x: Add regulator support
From: Mark Brown @ 2011-10-17 14:33 UTC (permalink / raw)
To: Robert MARKLUND; +Cc: netdev@vger.kernel.org, Steve Glendinning, Mathieu Poirer
In-Reply-To: <2B1D156D95AE9B4EAD379CB9E465FE7324AB09E052@EXDCVYMBSTM005.EQ1STM.local>
On Mon, Oct 17, 2011 at 04:13:47PM +0200, Robert MARKLUND wrote:
> > You should fix your mail client to word wrap within paragraphs, I've
> > reformatted it for legibility. Also leave a blank line between
> > paragraphs for the same reason.
> I have tried but it's not as easy as it sounds :)
> Does it look better now ?
Yes, thanks.
> > No, you should do what all the other drivers do and actually pay
> > attention to the errors. If we can't get power to the device that's a
> > pretty serious problem and the driver ought to fail.
> Then I don't understand the initial comment.
> Can you please elaborate that one.
If we fail to grab a critical resource for the device like the power
supply then we should be failing passing the error back. As I keep
saying this is what all the other regulator consumers are doing.
^ permalink raw reply
* Re: [PATCH 2/2] bridge: allow forwarding some link local frames
From: Ed Swierk @ 2011-10-17 14:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, netdev
In-Reply-To: <20111004041509.292932641@vyatta.com>
Why is forwarding LLDP (01-80-C2-00-00-0E) frames forbidden? I'm
testing LLDP in a virtual topology and need the bridge to forward
them.
If we're worried about standards, there is justification for allowing
forwarding of LLDP frames. 802.1d-2005 specifies two classes of
bridge, customer (C-VLAN) and provider (S-VLAN). Customer bridge is
just new terminology for what was previously just called an
802.1d-compliant bridge, while provider bridge is a new class that
transparently forwards certain control frames.
The only MAC addresses that are not supposed to be forwarded by either
customer or provider bridges are:
IEEE 802.3 Full Duplex PAUSE operation (01-80-C2-00-00-01)
IEEE 802.3 Slow_Protocols_Multicast address (01-80-C2-00-00-02)
IEEE 802.1X PAE address (01-80-C2-00-00-03)
Provider Bridge Group Address (01-80-C2-00-00-08)
Customer bridges are also not supposed to forward these addresses:
Bridge Group Address (01-80-C2-00-00-00)
Provider Bridge GVRP Address (01-80-C2-00-00-0D)
IEEE 802.1AB Link Layer Discovery Protocol multicast address (01-80-C2-00-00-0E)
My application requires a bridge between a pair of interfaces that
forwards (at least) LLDP frames; call this a provider bridge if you
care about standards conformance. It sounds like others require
forwarding 802.1X PAE frames, which appears non-conformant in any
case.
Standards aside, given that the default behavior is safe and that
/sys/class/net/brX/bridge/group_fwd_mask is unlikely to be modified by
accident by a casual user, can we just remove the
BR_GROUPFWD_RESTRICTED mask and allow users to forward whatever they
want?
--Ed
^ permalink raw reply
* Re: [PATCH v2 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: Kumar Gala @ 2011-10-17 14:48 UTC (permalink / raw)
To: Grant Likely
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <20110930003214.GB12606-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
On Sep 29, 2011, at 7:32 PM, Grant Likely wrote:
> On Thu, Sep 29, 2011 at 04:31:12PM -0400, David Miller wrote:
>> From: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>> Date: Tue, 27 Sep 2011 16:26:52 -0700
>>
>>> v2: Update bindings to use "reg" and "mdio-parent-bus" insutead of
>>> "cell-index" and "parent-bus"
>>
>> Grant, when the final version of this patch set is ready how do
>> you want to handle merging it in?
>>
>> I think it would be safe to merge this via your tree, since the
>> changes made to existing network driver files are rather trivial and
>> thus merge conflict friendly.
>
> Your tree or mine, I'm happy either way. Even if there were
> conflicts, they would be trivial.
>
> Sure, I'll take care of merging it when I see an ack from you.
>
>> Actually, I feel like we've discussed this before :-)
>
> :)
>
> g.
Any updates to these patches?
- k
^ permalink raw reply
* Re: [PATCH] dev: use ifindex hash for dev_seq_ops
From: Stephen Hemminger @ 2011-10-17 15:12 UTC (permalink / raw)
To: Daniel Baluta
Cc: Eric Dumazet, Mihai Maruseac, davem, mirq-linux, therbert, jpirko,
netdev, linux-kernel, Mihai Maruseac
In-Reply-To: <CAEnQRZCWBhTy24WkWoC_wy11YuLxWQ3GWr3v1=JcGvprq4AtmA@mail.gmail.com>
On Mon, 17 Oct 2011 11:03:54 +0300
Daniel Baluta <dbaluta@ixiacom.com> wrote:
> > This assumes device ifindexes are contained in a small range
> > [N .. N + X]
> >
> > I understand this can help some benchmarks, but in real world this wont
> > help that much once ifindexes are 'fragmented' (If really this multi
> > thousand devices stuff is for real)
> >
> > Listen, we currently have 256 slots in the hash table.
> >
> > Can we try to make 'offset' something like (slot_number<<24) +
> > (position in hash chain [slot_number]), instead of (position in devices
> > global list)
>
>
> Eric, we can refine the idea of our first patch [1], where we recorded
> the (bucket, offset) pair. Stephen, do you agree with this?
>
>
> thanks,
> Daniel.
>
> [1] http://patchwork.ozlabs.org/patch/118331/
Using buckets is fine, my idea about ifindex was just to try and
preserve the order, but it doesn't matter.
^ permalink raw reply
* Re: [PATCH 2/2] bridge: allow forwarding some link local frames
From: Stephen Hemminger @ 2011-10-17 15:18 UTC (permalink / raw)
To: Ed Swierk; +Cc: David S. Miller, netdev
In-Reply-To: <CAF5U64AYRhZ1e0=-RhSemgaOnewTQSpAoRY2FUrFr252PG98Pw@mail.gmail.com>
On Mon, 17 Oct 2011 07:35:53 -0700
Ed Swierk <eswierk@bigswitch.com> wrote:
> Why is forwarding LLDP (01-80-C2-00-00-0E) frames forbidden? I'm
> testing LLDP in a virtual topology and need the bridge to forward
> them.
>
> If we're worried about standards, there is justification for allowing
> forwarding of LLDP frames. 802.1d-2005 specifies two classes of
> bridge, customer (C-VLAN) and provider (S-VLAN). Customer bridge is
> just new terminology for what was previously just called an
> 802.1d-compliant bridge, while provider bridge is a new class that
> transparently forwards certain control frames.
Because in current 802.1Q (2005) standard there explicit language
that LLDP should not be forwarded. In Section 7.5
Frames that carry control information to determine the active
topology and current extent of each VLAN, i.e., spanning tree
and GVRP BPDUs, and frames from other link constrained
protocols, such as EAPOL and LLDP, are not forwarded.
Permanently configured static entries in the filtering database
(8.2, 8.3, and 8.12) ensure that such frames are discarded by
the Forwarding Process (8.6).
> The only MAC addresses that are not supposed to be forwarded by either
> customer or provider bridges are:
>
> IEEE 802.3 Full Duplex PAUSE operation (01-80-C2-00-00-01)
> IEEE 802.3 Slow_Protocols_Multicast address (01-80-C2-00-00-02)
> IEEE 802.1X PAE address (01-80-C2-00-00-03)
> Provider Bridge Group Address (01-80-C2-00-00-08)
>
> Customer bridges are also not supposed to forward these addresses:
>
> Bridge Group Address (01-80-C2-00-00-00)
> Provider Bridge GVRP Address (01-80-C2-00-00-0D)
> IEEE 802.1AB Link Layer Discovery Protocol multicast address (01-80-C2-00-00-0E)
>
> My application requires a bridge between a pair of interfaces that
> forwards (at least) LLDP frames; call this a provider bridge if you
> care about standards conformance. It sounds like others require
> forwarding 802.1X PAE frames, which appears non-conformant in any
> case.
>
> Standards aside, given that the default behavior is safe and that
> /sys/class/net/brX/bridge/group_fwd_mask is unlikely to be modified by
> accident by a casual user, can we just remove the
> BR_GROUPFWD_RESTRICTED mask and allow users to forward whatever they
Since EAPOL is allowed, and there is a use case for LLDP, allowing
that is probably okay.
I would prefer not to let user break standards by default. You of course are
free to compile what ever you want
^ permalink raw reply
* Re: [PATCH 1/1] ethtool: add ETHTOOL_{G,S}CHANNEL support.
From: Ben Hutchings @ 2011-10-17 15:20 UTC (permalink / raw)
To: Sucheta Chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1317988730-4197-2-git-send-email-sucheta.chakraborty@qlogic.com>
On Fri, 2011-10-07 at 04:58 -0700, Sucheta Chakraborty wrote:
> Used to configure number of tx/ rx/ other channels.
> Reqd. man page changes are included.
[...]
Applied. Thanks and sorry for the delay.
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] iproute2: Conforming to -D_FORTIFY_SOURCE=2 restrictions
From: Stephen Hemminger @ 2011-10-17 15:23 UTC (permalink / raw)
To: Bin Li; +Cc: netdev
In-Reply-To: <CAGBH1r6P_nmVhSQ7d9sj1qU_1VY7QssWm3ftS4mNcQjyAuCcqA@mail.gmail.com>
On Mon, 17 Oct 2011 15:35:35 +0800
Bin Li <libin.charles@gmail.com> wrote:
> (gdb) l
> 161 len = slen;
> 162 if (len > 0) {
> 163 if (len > max)
> 164 invarg("\"ALGOKEY\" makes buffer
> overflow\n", key);
> 165
> 166 strncpy(buf, key, len);
> 167 }
> 168 }
> 169
> 170 alg->alg_key_len = len * 8;
> (gdb) up
> #8 xfrm_state_modify (cmd=<optimized out>, flags=<optimized out>, argc=1,
> argv=0x7fffffffe370) at xfrm_state.c:406
> 406 xfrm_algo_parse((void *)&alg, type,
> name, key,
>
> the compiler passes zero to __builtin___strncpy_chk as the buffer size.
> xfrm_algo_parse is inlined into xfrm_state_modify.
I don't understand, looks like a compiler bug. Call strncpy with
0 length should not be possible since the check was 3 lines
before for len > 0.
^ permalink raw reply
* RE: [PATCH] smsc911x: Add regulator support
From: Robert MARKLUND @ 2011-10-17 15:28 UTC (permalink / raw)
To: Mark Brown; +Cc: netdev@vger.kernel.org, Steve Glendinning, Mathieu Poirer
In-Reply-To: <20111017143358.GI5448@sirena.org.uk>
> -----Original Message-----
> From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com]
> Sent: den 17 oktober 2011 16:34
> To: Robert MARKLUND
> Cc: netdev@vger.kernel.org; Steve Glendinning; Mathieu Poirer
> Subject: Re: [PATCH] smsc911x: Add regulator support
>
> On Mon, Oct 17, 2011 at 04:13:47PM +0200, Robert MARKLUND wrote:
>
> > > You should fix your mail client to word wrap within paragraphs, I've
> > > reformatted it for legibility. Also leave a blank line between
> > > paragraphs for the same reason.
>
> > I have tried but it's not as easy as it sounds :)
> > Does it look better now ?
>
> Yes, thanks.
>
> > > No, you should do what all the other drivers do and actually pay
> > > attention to the errors. If we can't get power to the device that's a
> > > pretty serious problem and the driver ought to fail.
>
> > Then I don't understand the initial comment.
> > Can you please elaborate that one.
>
> If we fail to grab a critical resource for the device like the power
> supply then we should be failing passing the error back. As I keep
> saying this is what all the other regulator consumers are doing.
Most of the boards out there don't have any regulators for the chip(power is always on).
So when we can't get the regulator, we assume that the power is already on.
That's why it hasn't been implemented before.
So adding this functionality will make all the other boards out there fail, to start the driver.
/R
^ permalink raw reply
* Re: [PATCH] smsc911x: Add regulator support
From: Mark Brown @ 2011-10-17 15:38 UTC (permalink / raw)
To: Robert MARKLUND; +Cc: netdev@vger.kernel.org, Steve Glendinning, Mathieu Poirer
In-Reply-To: <2B1D156D95AE9B4EAD379CB9E465FE7324AB09E0EE@EXDCVYMBSTM005.EQ1STM.local>
On Mon, Oct 17, 2011 at 05:28:08PM +0200, Robert MARKLUND wrote:
> > If we fail to grab a critical resource for the device like the power
> > supply then we should be failing passing the error back. As I keep
> > saying this is what all the other regulator consumers are doing.
> Most of the boards out there don't have any regulators for the chip(power is always on).
> So when we can't get the regulator, we assume that the power is already on.
> That's why it hasn't been implemented before.
> So adding this functionality will make all the other boards out there fail, to start the driver.
Clearly this issue is going to apply to every single user of the
regulator API which is one reason why it's insane to open code handling
of missing regulators in individual regulator consumer drivers. As I
keep saying you should unconditionally use the regulators and let the
regulator API facilities for stubbing itself out deal with this.
^ permalink raw reply
* Re: [PATCH v2 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: David Daney @ 2011-10-17 15:41 UTC (permalink / raw)
To: Kumar Gala
Cc: Grant Likely, David Miller, devicetree-discuss, linux-kernel,
netdev
In-Reply-To: <C81814FF-4E56-4B28-8043-F874EE1D6B51@kernel.crashing.org>
On 10/17/2011 07:48 AM, Kumar Gala wrote:
>
> On Sep 29, 2011, at 7:32 PM, Grant Likely wrote:
>
>> On Thu, Sep 29, 2011 at 04:31:12PM -0400, David Miller wrote:
>>> From: David Daney<david.daney@cavium.com>
>>> Date: Tue, 27 Sep 2011 16:26:52 -0700
>>>
>>>> v2: Update bindings to use "reg" and "mdio-parent-bus" insutead of
>>>> "cell-index" and "parent-bus"
>>>
>>> Grant, when the final version of this patch set is ready how do
>>> you want to handle merging it in?
>>>
>>> I think it would be safe to merge this via your tree, since the
>>> changes made to existing network driver files are rather trivial and
>>> thus merge conflict friendly.
>>
>> Your tree or mine, I'm happy either way. Even if there were
>> conflicts, they would be trivial.
>>
>> Sure, I'll take care of merging it when I see an ack from you.
>>
>>> Actually, I feel like we've discussed this before :-)
>>
>> :)
>>
>> g.
>
> Any updates to these patches?
Not yet, so you didn't miss anything.
They are on my to-do list though
David Daney
^ permalink raw reply
* [PATCH] iproute2: update CAN bitrate SJW help text
From: Oliver Hartkopp @ 2011-10-17 15:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Wolfgang Grandegger, Linux Netdev List, linux-can
The ip-tool from iproute2 already supports to pass a user defined SJW
value for the in-kernel bittiming calculation. This patch updates the
help text accordingly.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
diff --git a/ip/iplink_can.c b/ip/iplink_can.c
index c8af4bc..00e7d98 100644
--- a/ip/iplink_can.c
+++ b/ip/iplink_can.c
@@ -23,7 +23,8 @@ static void usage(void)
{
fprintf(stderr,
"Usage: ip link set DEVICE type can\n"
- "\t[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] | \n"
+ "\t[ bitrate BITRATE [ sample-point SAMPLE-POINT ] [ sjw SJW "
+ "] ] | \n"
"\t[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1\n "
"\t phase-seg2 PHASE-SEG2 [ sjw SJW ] ]\n"
"\n"
^ permalink raw reply related
* [PATCH] NET: asix: fix ethtool -e for AX88178 USB dongle
From: Grant Grundler @ 2011-10-17 15:51 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, allan, Freddy Xin, Grant Grundler
"ethtool -e ethX" dumps EEPROM data. Patch sets EEPROM length for device.
Ethtool works alot better when the kernel believes the length is > 0.
From: Allan Chou <allan@asix.com.tw>
Signed-off-by: Grant Grundler <grundler@chromium.org>
---
drivers/net/usb/asix.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/asix.c b/drivers/net/usb/asix.c
index 66e5ccb..03a1621 100644
--- a/drivers/net/usb/asix.c
+++ b/drivers/net/usb/asix.c
@@ -1399,6 +1399,9 @@ static int ax88178_bind(struct usbnet *dev, struct usb_interface *intf)
int ret;
u8 buf[ETH_ALEN];
u32 phyid;
+ struct asix_data *data = (struct asix_data *)&dev->data;
+
+ data->eeprom_len = AX88772_EEPROM_LEN;
usbnet_get_endpoints(dev,intf);
--
1.7.2.3
^ permalink raw reply related
* Re: [net-next 2/6 v2] igb: Check if subordinate VFs are assigned to virtual machines
From: Joe Perches @ 2011-10-17 15:53 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, Greg Rose, netdev, gospo, sassmann, Konrad Rzeszutek Wilk,
Christian Benvenuti, Sathya Perla, Dimitris Michailidis,
Jon Mason, James Smart
In-Reply-To: <1318854062-3628-3-git-send-email-jeffrey.t.kirsher@intel.com>
On Mon, 2011-10-17 at 05:20 -0700, Jeff Kirsher wrote:
> From: Greg Rose <gregory.v.rose@intel.com>
Trivia:
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
[]
> + if (old_vfs) {
> + dev_info(&pdev->dev, "%d pre-allocated VFs found - override "
> + "max_vfs setting of %d\n", old_vfs, max_vfs);
[]
> + dev_err(&pdev->dev, "Unable to allocate memory for VF "
> + "Data Storage\n");
The dev_err line isn't really necessary.
There is a generic allocation failure dump_stack.
Also, please don't split formats into multiple lines.
^ permalink raw reply
* Re: sky2: only 10Mb/s
From: Stephen Hemminger @ 2011-10-17 15:56 UTC (permalink / raw)
To: Pavel Mateja; +Cc: netdev
In-Reply-To: <201110171434.50436.pavel@netsafe.cz>
On Mon, 17 Oct 2011 14:34:50 +0200
Pavel Mateja <pavel@netsafe.cz> wrote:
> Hi,
> I tested new kernel and I have found out I have only 10Mb/s link instead of
> 100Mb/s to my router.
> If I did the git bisect right it was caused by commit
> 4fb99cd6ac4fe6d03a334a6f4ebb2bbfc4b479ed which was submitted by you.
>
> My card is (lspci -v):
> 05:00.0 Ethernet controller: Marvell Technology Group Ltd. Yukon Optima
> 88E8059 [PCIe Gigabit Ethernet Controller with AVB] (rev 11)
> Subsystem: ASUSTeK Computer Inc. Device 8439
> Flags: bus master, fast devsel, latency 0, IRQ 80
> Memory at fe6fc000 (64-bit, non-prefetchable) [size=16K]
> I/O ports at b800 [size=256]
> Expansion ROM at fe6c0000 [disabled] [size=128K]
> Capabilities: [48] Power Management version 3
> Capabilities: [5c] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [c0] Express Legacy Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [130] Device Serial Number a5-89-6d-ff-ff-30-cf-20
> Kernel driver in use: sky2
>
> I'm quite sure it's related to Yukon Optima because "Ethernet controller:
> Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller" in my
> work computer has 100Mb/s with the same kernel and driver.
>
> I got no response on netdev@vger.kernel.org.
> Can you help me?
What is output of dmesg for sky2.
dmesg | grep sky2
The problem is related to PHY setup. Almost all of that is copied from the
vendor driver. It might take a few steps to fix because I don't think I
have one of those cards handy.
^ permalink raw reply
* Re: [net-next 6/6] ixgbe: change the eeprom version reported by ethtool
From: Joe Perches @ 2011-10-17 15:57 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Emil Tantilov, netdev, gospo, sassmann
In-Reply-To: <1318854062-3628-7-git-send-email-jeffrey.t.kirsher@intel.com>
On Mon, 2011-10-17 at 05:21 -0700, Jeff Kirsher wrote:
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> Use 32bit value starting at offset 0x2d for displaying the firmware
> version in ethtool. This should work for all current ixgbe HW
[]
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
[]
> - snprintf(firmware_version, sizeof(firmware_version), "%d.%d-%d",
> - (adapter->eeprom_version & 0xF000) >> 12,
> - (adapter->eeprom_version & 0x0FF0) >> 4,
> - adapter->eeprom_version & 0x000F);
> + nvm_track_id = (adapter->eeprom_verh << 16) |
> + adapter->eeprom_verl;
> + snprintf(firmware_version, sizeof(firmware_version), "0x%08x",
> + nvm_track_id);
Is ethtool output like proc output considered an abi
that should not be changed?
^ permalink raw reply
* Re: [PATCH] iproute2: update CAN bitrate SJW help text
From: Stephen Hemminger @ 2011-10-17 15:58 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: Wolfgang Grandegger, Linux Netdev List, linux-can
In-Reply-To: <4E9C4D29.7010302@hartkopp.net>
On Mon, 17 Oct 2011 17:43:37 +0200
Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> The ip-tool from iproute2 already supports to pass a user defined SJW
> value for the in-kernel bittiming calculation. This patch updates the
> help text accordingly.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
> ---
>
> diff --git a/ip/iplink_can.c b/ip/iplink_can.c
> index c8af4bc..00e7d98 100644
> --- a/ip/iplink_can.c
> +++ b/ip/iplink_can.c
> @@ -23,7 +23,8 @@ static void usage(void)
> {
> fprintf(stderr,
> "Usage: ip link set DEVICE type can\n"
> - "\t[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] | \n"
> + "\t[ bitrate BITRATE [ sample-point SAMPLE-POINT ] [ sjw SJW "
> + "] ] | \n"
> "\t[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1\n "
> "\t phase-seg2 PHASE-SEG2 [ sjw SJW ] ]\n"
> "\n"
Please update man page as well.
^ permalink raw reply
* Re: [PATCH] bnx2x: Adding FW 7.0.29.0
From: Dmitry Kravkov @ 2011-10-17 16:12 UTC (permalink / raw)
To: dwmw2@infradead.org
Cc: ben@decadent.org.uk, netdev@vger.kernel.org, Eilon Greenstein
In-Reply-To: <1318860047-5044-1-git-send-email-dmitry@broadcom.com>
Adding netdev
On Mon, 2011-10-17 at 07:00 -0700, Dmitry Kravkov wrote:
> Includes fixes for the following issues:
> 1. (iSCSI) Arrival of un-solicited ASYNC message causes
> firmware to abort the connection with RST.
> 2. (FCoE) There is a probability that truncated FCoE packet on
> RX path won't get detected which might lead to FW assert.
> 3. (iSCSI) Arrival of target-initiated NOP-IN during intense
> ISCSI traffic might lead to FW assert.
> 4. (iSCSI) Chip hangs when in case of retransmission not aligned
> to 4-bytes from the beginning of iSCSI PDU.
> 5. (FCoE) Arrival of packets beyond task IO size can lead to crash.
>
>
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> ---
> The patch also available at:
> http://linux.broadcom.com/eilong/FW-7.0.29.0/0001-bnx2x-Adding-FW-7.0.29.0.patch
> ___
^ permalink raw reply
* Re: [net-next 5/6] ixgbe: add hardware timestamping support
From: Richard Cochran @ 2011-10-17 16:44 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Jacob Keller, netdev, gospo, sassmann
In-Reply-To: <1318854062-3628-6-git-send-email-jeffrey.t.kirsher@intel.com>
On Mon, Oct 17, 2011 at 05:21:01AM -0700, Jeff Kirsher wrote:
> The cyclecounter has the potential to miss a wrap-around of the
> systim register (this should occur no more often than every 35
> seconds) unless some activity regarding the cycle counter occurs at
> least once within this time. This version adds a cycle counter read
> every time the watchdog task is run, which should occur at least once
> within this timeframe. Any packets being timestamped will also count
> as a read due to the call to timecompare_update.
So, is this wrap around due to the fact that you are tied to the
system time via time_compare? Or, putting it another way, can't you
program the hardware time stamping unit so that the registers have
some reasonable resolution (like 64 bits worth of nanoseconds) and
just offer RAW timestamps?
I would really like to move away from the timecompare hacks and
towards a proper PHC->SYS PPS solution.
> This version fixes an issue regarding timecompare not updating
> detected skew after the clock offset is changed due to ptpd or outside
> influence from the OS. Now the skew detection is forced just before we
> hand a timestamp up to the kernel stack
Again, doing the update thing on every packet won't work for real
world PTP scenarios.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH net-next] tcp: reduce memory needs of out of order queue
From: Rick Jones @ 2011-10-17 16:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1318660775.2525.29.camel@edumazet-laptop>
>
> Rick, could you redo the test, using following bit on receiver :
>
> echo 1>/proc/sys/net/ipv4/tcp_adv_win_scale
raj@tardy:~/netperf2_trunk$ netstat -s > before; src/netperf -H
raj-8510w.americas.hpqcorp.net -t tcp_rr -- -b 256 -D -o
throughput,local_transport_retrans,remote_transport_retrans,lss_size_end,rsr_size_end
; netstat -s > afterMIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0
(0.0.0.0) port 0 AF_INET to internal-host.americas.hpqcorp.net
(16.89.245.115) port 0 AF_INET : nodelay : first burst 256
Throughput,Local Transport Retransmissions,Remote Transport
Retransmissions,Local Send Socket Size Final,Remote Recv Socket Size Final
78527.68,289,0,16384,98304
Deltas on the receiver:
TcpExt:
27 packets pruned from receive queue because of socket buffer overrun
0 TCP sockets finished time wait in fast timer
0 delayed acks sent
0 delayed acks further delayed because of locked socket
Quick ack mode was activated 0 times
19 packets directly queued to recvmsg prequeue.
0 bytes directly in process context from backlog
670 bytes directly received in process context from prequeue
739983 packet headers predicted
14 packets header predicted and directly queued to user
127 acknowledgments not containing data payload received
235774 predicted acknowledgments
0 other TCP timeouts
6553 packets collapsed in receive queue due to low socket buffer
0 DSACKs sent for old packets
TCPBacklogDrop: 294
So, moving on to:
> If you still have collapses/retransmits, you then could try :
>
> echo -2>/proc/sys/net/ipv4/tcp_adv_win_scale
raj@tardy:~/netperf2_trunk$ netstat -s > before; src/netperf -H
raj-8510w.americas.hpqcorp.net -t tcp_rr -- -b 256 -D -o
throughput,local_transport_retrans,remote_transport_retrans,lss_size_end,rsr_size_end
; netstat -s > after
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to internal-host.americas.hpqcorp.net (16.89.245.115) port 0 AF_INET :
nodelay : first burst 256
Throughput,Local Transport Retransmissions,Remote Transport
Retransmissions,Local Send Socket Size Final,Remote Recv Socket Size Final
95981.83,0,0,121200,156600
No retransmissions in that one.
rick
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: inet6_connection_sock.h needs flowi
From: Christoph Paasch @ 2011-10-17 16:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111016.201310.2196482600418365872.davem@davemloft.net>
On 10/17/2011 03:13 AM, David Miller wrote:
> From: Christoph Paasch<christoph.paasch@uclouvain.be>
> Date: Sun, 16 Oct 2011 12:13:39 +0300
>
>> On 10/16/2011 01:41 AM, David Miller wrote:
>>> From: Christoph Paasch<christoph.paasch@uclouvain.be>
>>> Date: Sat, 15 Oct 2011 12:34:24 +0300
>>>
>>>> Otherwise we have a compiler-warning in c-files not including
>>>> net/flow.h
>>>> before inet6_connection_sock.h .
>>>>
>>>> Signed-off-by: Christoph Paasch<christoph.paasch@uclouvain.be>
>>>
>>> Example? I've never seen this warning.
>>
>> Currently, all the c-files that include inet6_connection_sock.h
>> indirectly include flow.h before inet6_connection_sock.h. Thus
>> currently there is no compiler-warning.
>
> Then there is no bug you are fixing.
You're right. The patch did not intend to fix a bug (maybe the
commit-message should have been more clear about that).
It was intended to make inet6_connection_sock.h not rely on the c-files
to include flow.h, even if they would not need to. And to do the same
for struct flowi as it is done for the other structs in this
header-file. Thus it was rather a coding-style patch... :)
But ok, maybe I should not try to change something which is not really
broken... ;-)
Christoph
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
--
^ 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