* [PATCH v2 08/15] unix: declaring unix protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring unix protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/unix/af_unix.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index e4768c1..7f109e6 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -616,6 +616,7 @@ static struct proto unix_proto = {
.name = "UNIX",
.owner = THIS_MODULE,
.obj_size = sizeof(struct unix_sock),
+ .has_own_proc_entry= 1,
};
/*
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 09/15] netlink: declaring netlink protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring netlink protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/netlink/af_netlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 5463969..9094be5 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -410,6 +410,7 @@ static struct proto netlink_proto = {
.name = "NETLINK",
.owner = THIS_MODULE,
.obj_size = sizeof(struct netlink_sock),
+ .has_own_proc_entry= 1,
};
static int __netlink_create(struct net *net, struct socket *sock,
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 10/15] ipv6: declaring tcpv6 protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring tcpv6 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv6/tcp_ipv6.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index aa41b0e..741cb3b 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -2017,6 +2017,7 @@ struct proto tcpv6_prot = {
#ifdef CONFIG_MEMCG_KMEM
.proto_cgroup = tcp_proto_cgroup,
#endif
+ .has_own_proc_entry= 1,
};
static const struct inet6_protocol tcpv6_protocol = {
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 12/15] ipv6: declaring udplitev6 protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring udplitev6 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv6/udplite.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/udplite.c b/net/ipv6/udplite.c
index 1d08e21..9013897 100644
--- a/net/ipv6/udplite.c
+++ b/net/ipv6/udplite.c
@@ -57,6 +57,7 @@ struct proto udplitev6_prot = {
.compat_getsockopt = compat_udpv6_getsockopt,
#endif
.clear_sk = sk_prot_clear_portaddr_nulls,
+ .has_own_proc_entry= 1,
};
static struct inet_protosw udplite6_protosw = {
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 13/15] ipv6: declaring rawv6 protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring rawv6 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv6/raw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index ef0579d..62ac59f 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -1226,6 +1226,7 @@ struct proto rawv6_prot = {
.compat_getsockopt = compat_rawv6_getsockopt,
.compat_ioctl = compat_rawv6_ioctl,
#endif
+ .has_own_proc_entry= 1,
};
#ifdef CONFIG_PROC_FS
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 14/15] ax25: declaring ax25 protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring ax25 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ax25/af_ax25.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index 779095d..ff23c8a 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -803,6 +803,7 @@ static struct proto ax25_proto = {
.name = "AX25",
.owner = THIS_MODULE,
.obj_size = sizeof(struct sock),
+ .has_own_proc_entry= 1,
};
static int ax25_create(struct net *net, struct socket *sock, int protocol,
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 15/15] ipx: declaring ipx protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring ipx protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipx/af_ipx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c
index dfd6faa..14be087 100644
--- a/net/ipx/af_ipx.c
+++ b/net/ipx/af_ipx.c
@@ -1345,6 +1345,7 @@ static struct proto ipx_proto = {
.name = "IPX",
.owner = THIS_MODULE,
.obj_size = sizeof(struct ipx_sock),
+ .has_own_proc_entry= 1,
};
static int ipx_create(struct net *net, struct socket *sock, int protocol,
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 02/15] ipv4: declaring udp protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring udp protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv4/udp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index b4c3582..a16c4fa 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1963,6 +1963,7 @@ struct proto udp_prot = {
.compat_getsockopt = compat_udp_getsockopt,
#endif
.clear_sk = sk_prot_clear_portaddr_nulls,
+ .has_own_proc_entry= 1,
};
EXPORT_SYMBOL(udp_prot);
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 11/15] ipv6: declaring udpv6 protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring udpv6 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv6/udp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 99d0077..1b28eaf 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1537,6 +1537,7 @@ struct proto udpv6_prot = {
.compat_getsockopt = compat_udpv6_getsockopt,
#endif
.clear_sk = sk_prot_clear_portaddr_nulls,
+ .has_own_proc_entry= 1,
};
static struct inet_protosw udpv6_protosw = {
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 04/15] ipv4: declaring udplite protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring udplite protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv4/udplite.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/udplite.c b/net/ipv4/udplite.c
index 2c46acd..14c9dec 100644
--- a/net/ipv4/udplite.c
+++ b/net/ipv4/udplite.c
@@ -62,6 +62,7 @@ struct proto udplite_prot = {
.compat_getsockopt = compat_udp_getsockopt,
#endif
.clear_sk = sk_prot_clear_portaddr_nulls,
+ .has_own_proc_entry= 1,
};
EXPORT_SYMBOL(udplite_prot);
--
1.7.11.2
^ permalink raw reply related
* Re: [PATCH net-next] net: reorganize IP MIB values
From: Stephen Hemminger @ 2012-08-11 20:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1344148439.9299.1570.camel@edumazet-glaptop>
On Sun, 05 Aug 2012 08:33:59 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Reduce IP latencies by placing hot MIB IP fields in a single cache line.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> include/linux/snmp.h | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/snmp.h b/include/linux/snmp.h
> index 00bc189..aa02b9e 100644
> --- a/include/linux/snmp.h
> +++ b/include/linux/snmp.h
> @@ -18,7 +18,14 @@
> enum
> {
> IPSTATS_MIB_NUM = 0,
> +/* frequently written fields in fast path, kept in same cache line */
> IPSTATS_MIB_INPKTS, /* InReceives */
> + IPSTATS_MIB_INOCTETS, /* InOctets */
> + IPSTATS_MIB_INDELIVERS, /* InDelivers */
> + IPSTATS_MIB_OUTFORWDATAGRAMS, /* OutForwDatagrams */
> + IPSTATS_MIB_OUTPKTS, /* OutRequests */
> + IPSTATS_MIB_OUTOCTETS, /* OutOctets */
> +/* other fields */
> IPSTATS_MIB_INHDRERRORS, /* InHdrErrors */
> IPSTATS_MIB_INTOOBIGERRORS, /* InTooBigErrors */
> IPSTATS_MIB_INNOROUTES, /* InNoRoutes */
> @@ -26,9 +33,6 @@ enum
> IPSTATS_MIB_INUNKNOWNPROTOS, /* InUnknownProtos */
> IPSTATS_MIB_INTRUNCATEDPKTS, /* InTruncatedPkts */
> IPSTATS_MIB_INDISCARDS, /* InDiscards */
> - IPSTATS_MIB_INDELIVERS, /* InDelivers */
> - IPSTATS_MIB_OUTFORWDATAGRAMS, /* OutForwDatagrams */
> - IPSTATS_MIB_OUTPKTS, /* OutRequests */
> IPSTATS_MIB_OUTDISCARDS, /* OutDiscards */
> IPSTATS_MIB_OUTNOROUTES, /* OutNoRoutes */
> IPSTATS_MIB_REASMTIMEOUT, /* ReasmTimeout */
> @@ -42,8 +46,6 @@ enum
> IPSTATS_MIB_OUTMCASTPKTS, /* OutMcastPkts */
> IPSTATS_MIB_INBCASTPKTS, /* InBcastPkts */
> IPSTATS_MIB_OUTBCASTPKTS, /* OutBcastPkts */
> - IPSTATS_MIB_INOCTETS, /* InOctets */
> - IPSTATS_MIB_OUTOCTETS, /* OutOctets */
> IPSTATS_MIB_INMCASTOCTETS, /* InMcastOctets */
> IPSTATS_MIB_OUTMCASTOCTETS, /* OutMcastOctets */
> IPSTATS_MIB_INBCASTOCTETS, /* InBcastOctets */
>
>
Will this break kernel ABI since these are exported in sanitized headers?
^ permalink raw reply
* Re: [PATCH] net: add new QCA alx ethernet driver
From: Stephen Hemminger @ 2012-08-11 20:50 UTC (permalink / raw)
To: cjren
Cc: davem, netdev, linux-kernel, qca-linux-team, nic-devel,
Xiong Huang, Hao-Ran Liu(Joseph Liu), Joe Perches,
Luis R. Rodriguez
In-Reply-To: <1344507270-2907-1-git-send-email-cjren@qca.qualcomm.com>
On Thu, 9 Aug 2012 18:14:30 +0800
<cjren@qca.qualcomm.com> wrote:
> + strcpy(netdev->name, "eth%d");
> + retval = register_netdev(netdev);
The strcpy is unnecessary, alloc_etherdev already sets that.
^ permalink raw reply
* Re: [Question]About KVM network zero-copy feature!
From: Stephen Hemminger @ 2012-08-11 20:55 UTC (permalink / raw)
To: Peter Huang(Peng); +Cc: kvm, mst, netdev, virtualization, avi
In-Reply-To: <50248148.4070204@huawei.com>
On Fri, 10 Aug 2012 11:34:32 +0800
"Peter Huang(Peng)" <peter.huangpeng@huawei.com> wrote:
> Hi,All
>
> I searched from git-log, and found that until now we have vhost TX zero-copy experiment feature, how
> about RX zero-copy?
>
> For XEN, net-back also only has TX zero-copy, Is there any reason that RX zero-copy still not implemented?
>
There is no guarantee that packet will ever be read by receiver. This means zero-copy could
create memory back pressure stalls.
^ permalink raw reply
* Re: [Question]About KVM network zero-copy feature!
From: Robert Vineyard @ 2012-08-11 21:54 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Peter Huang(Peng), kvm, mst, netdev, virtualization, avi
In-Reply-To: <20120811135556.58ddf48d@nehalam.linuxnetplumber.net>
> On Fri, 10 Aug 2012 11:34:32 +0800
> "Peter Huang(Peng)" <peter.huangpeng@huawei.com> wrote:
>
>> I searched from git-log, and found that until now we have vhost TX zero-copy experiment feature, how
>> about RX zero-copy?
On 08/11/2012 04:55 PM, Stephen Hemminger wrote:
> There is no guarantee that packet will ever be read by receiver. This means zero-copy could
> create memory back pressure stalls.
It would be handy if this could be an optional feature, perhaps not
enabled by default due to the problem with stalls you mentioned. I would
love to see RX zero-copy implemented natively in KVM, as it might
alleviate the need for custom solutions like vPF_RING:
http://www.ntop.org/products/pf_ring/vpf_ring/
Every time a packet is copied, especially from kernel space to user
space, there is an opportunity for it to be dropped on its way to the
receiving application - which is unacceptable when monitoring high-speed
networks for security or bandwidth accounting purposes.
I am attempting to find a highly-efficient way to deploy virtualized
network monitoring sensors (Snort, for example). Ideally I want to
exploit symmetric hardware-based RSS and SR-IOV functionality for
load-balancing and packet distribution completely in ASIC. I've found
other existing work in this area (also using custom drivers) indicating
significant performance gains in the non-virtualized case:
http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf
Is there any interest in exploring native RX zero-copy within the
mainline KVM networking code?
Thanks,
Robert Vineyard
^ permalink raw reply
* Re: [Question]About KVM network zero-copy feature!
From: Robert Vineyard @ 2012-08-12 0:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: xiaohui.xin, kvm, mst, netdev, Peter Huang(Peng), virtualization,
avi
In-Reply-To: <5026D49B.10305@tuffmail.com>
(adding Xin Xiaohui to the conversation for comment)
According to the NetworkingTodo page on the KVM wiki, zero-copy RX for
macvtap is in fact on the roadmap, assigned to Xin:
http://www.linux-kvm.org/page/NetworkingTodo
The Release Notes for RHEL 6.2 (originally published on 12/06/2011) also
specifically mention macvtap/vhost zero-copy capabilities as being
included as a Technology Preview:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/6.2_Release_Notes/virtualization.html
Since I've been unable to find much information on the current status of
this development, can anyone confirm if this functionality is still in
the works? If so, is there any planned ETA?
Thanks,
Robert Vineyard
On 08/11/2012 05:54 PM, Robert Vineyard wrote:
>> On Fri, 10 Aug 2012 11:34:32 +0800
>> "Peter Huang(Peng)" <peter.huangpeng@huawei.com> wrote:
>>
>>> I searched from git-log, and found that until now we have vhost TX
>>> zero-copy experiment feature, how
>>> about RX zero-copy?
>
> On 08/11/2012 04:55 PM, Stephen Hemminger wrote:
>> There is no guarantee that packet will ever be read by receiver. This
>> means zero-copy could
>> create memory back pressure stalls.
>
> It would be handy if this could be an optional feature, perhaps not
> enabled by default due to the problem with stalls you mentioned. I would
> love to see RX zero-copy implemented natively in KVM, as it might
> alleviate the need for custom solutions like vPF_RING:
>
> http://www.ntop.org/products/pf_ring/vpf_ring/
>
> Every time a packet is copied, especially from kernel space to user
> space, there is an opportunity for it to be dropped on its way to the
> receiving application - which is unacceptable when monitoring high-speed
> networks for security or bandwidth accounting purposes.
>
> I am attempting to find a highly-efficient way to deploy virtualized
> network monitoring sensors (Snort, for example). Ideally I want to
> exploit symmetric hardware-based RSS and SR-IOV functionality for
> load-balancing and packet distribution completely in ASIC. I've found
> other existing work in this area (also using custom drivers) indicating
> significant performance gains in the non-virtualized case:
>
> http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf
>
> Is there any interest in exploring native RX zero-copy within the
> mainline KVM networking code?
>
> Thanks,
> Robert Vineyard
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] macvtap: rcu_dereference outside read-lock section
From: David Miller @ 2012-08-12 1:16 UTC (permalink / raw)
To: yefremov.denis
Cc: mst, jasowang, ebiederm, ian.campbell, netdev, linux-kernel,
ldv-project
In-Reply-To: <1344679527-13377-1-git-send-email-yefremov.denis@gmail.com>
From: Denis Efremov <yefremov.denis@gmail.com>
Date: Sat, 11 Aug 2012 14:05:27 +0400
> - if (rcu_dereference(vlan->taps[i]) == q)
> + if (rcu_dereference_protected(vlan->taps[i],
> + lockdep_is_held(&macvtap_lock)) == q)
You must use the proper combination of TAB character and spaces
to line up the lockdep_is_held() argument with the first column
after openning "(" on the previous line.
Never be lazy and use only TABs.
^ permalink raw reply
* Re: [PATCH net-next] net: reorganize IP MIB values
From: David Miller @ 2012-08-12 1:19 UTC (permalink / raw)
To: shemminger; +Cc: eric.dumazet, netdev
In-Reply-To: <20120811134219.4a3b146d@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sat, 11 Aug 2012 13:42:19 -0700
> Will this break kernel ABI since these are exported in sanitized headers?
No, the tools parse the field names from the procfs output.
^ permalink raw reply
* [PATCH] bnx2x: Fix compiler warnings
From: Joren Van Onder @ 2012-08-12 3:10 UTC (permalink / raw)
To: eilong; +Cc: netdev, linux-kernel, Joren Van Onder
Fix the following compiler warnings:
- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:2908:3: warning: comparison
of distinct pointer types lacks a cast [enabled by default]
- drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:1709:7: warning: comparison
of distinct pointer types lacks a cast [enabled by default]
Signed-off-by: Joren Van Onder <joren.vanonder@gmail.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index 77bcd4c..463b9ec 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1278,7 +1278,7 @@ struct bnx2x {
#define BNX2X_FW_RX_ALIGN_START (1UL << BNX2X_RX_ALIGN_SHIFT)
#define BNX2X_FW_RX_ALIGN_END \
- max(1UL << BNX2X_RX_ALIGN_SHIFT, \
+ max_t(u64, 1UL << BNX2X_RX_ALIGN_SHIFT, \
SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
#define BNX2X_PXP_DRAM_ALIGN (BNX2X_RX_ALIGN_SHIFT - 5)
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2 01/15] net: proc entry showing inodes on sockfs and their types
From: David Miller @ 2012-08-12 4:04 UTC (permalink / raw)
To: yamato; +Cc: netdev, linux-kernel
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Sorry, you cannot do this.
You are adding a new lock and insert into a global list for
pretty much every socket created, that will destroy performance.
You also cannnot add new fields to socket listing procfs files,
it will break existing application which depend upon the existing
exact layout of those fields.
^ permalink raw reply
* Re: [PATCH v2 01/15] net: proc entry showing inodes on sockfs and their types
From: David Miller @ 2012-08-12 4:05 UTC (permalink / raw)
To: yamato; +Cc: netdev, linux-kernel
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
I also want to mention that I absolutely do not consider better lsof
support important at all.
So if you want to add this, it had to be exactly zero overhead and it
must not break anything that exists already. Your patch set violates
this on both counts.
^ permalink raw reply
* Re: [PATCH] bnx2x: Fix compiler warnings
From: Yuval Mintz @ 2012-08-12 4:50 UTC (permalink / raw)
To: Joren Van Onder; +Cc: eilong, netdev, linux-kernel
In-Reply-To: <1344741035-1493-1-git-send-email-joren.vanonder@gmail.com>
> Fix the following compiler warnings:
>
> - drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:2908:3: warning: comparison
> of distinct pointer types lacks a cast [enabled by default]
> - drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:1709:7: warning: comparison
> of distinct pointer types lacks a cast [enabled by default]
>
> Signed-off-by: Joren Van Onder <joren.vanonder@gmail.com>
Thanks Joren.
Acked-By: Yuval Mintz <yuvalmin@broadcom.com>
^ permalink raw reply
* [PATCH v2] macvtap: rcu_dereference outside read-lock section
From: Denis Efremov @ 2012-08-12 6:26 UTC (permalink / raw)
To: David S. Miller
Cc: Denis Efremov, Michael S. Tsirkin, Jason Wang, Eric W. Biederman,
Ian Campbell, netdev, linux-kernel, ldv-project
In-Reply-To: <20120811.181642.1587792778007257202.davem@davemloft.net>
rcu_dereference occurs in update section. Replacement by
rcu_dereference_protected in order to prevent lockdep
complaint.
Found by Linux Driver Verification project (linuxtesting.org)
Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
---
drivers/net/macvtap.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 0737bd4..0f0f9ce 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -94,7 +94,8 @@ static int get_slot(struct macvlan_dev *vlan, struct macvtap_queue *q)
int i;
for (i = 0; i < MAX_MACVTAP_QUEUES; i++) {
- if (rcu_dereference(vlan->taps[i]) == q)
+ if (rcu_dereference_protected(vlan->taps[i],
+ lockdep_is_held(&macvtap_lock)) == q)
return i;
}
--
1.7.7
^ permalink raw reply related
* Re: [PATCH v2 01/15] net: proc entry showing inodes on sockfs and their types
From: Masatake YAMATO @ 2012-08-12 6:44 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel
In-Reply-To: <20120811.210434.961670950702666620.davem@davemloft.net>
>
> Sorry, you cannot do this.
>
> You are adding a new lock and insert into a global list for
> pretty much every socket created, that will destroy performance.
I think there are no serious performance penalty in generally use.
Most frequently used types of sockets like tcp, udp, and unix are not
stored to the global list and don't touch the new lock at all.
Please, look at has_own_proc_entry in struct proto.
> You also cannnot add new fields to socket listing procfs files,
> it will break existing application which depend upon the existing
> exact layout of those fields.
Is there any strcut which can be extended?
Extending struct sock is o.k.?
Masatake YAMATO
^ permalink raw reply
* Re: [PATCH v2] macvtap: rcu_dereference outside read-lock section
From: Michael S. Tsirkin @ 2012-08-12 8:49 UTC (permalink / raw)
To: Denis Efremov
Cc: David S. Miller, Jason Wang, Eric W. Biederman, Ian Campbell,
netdev, linux-kernel, ldv-project
In-Reply-To: <1344752791-21140-1-git-send-email-yefremov.denis@gmail.com>
On Sun, Aug 12, 2012 at 10:26:31AM +0400, Denis Efremov wrote:
> rcu_dereference occurs in update section. Replacement by
> rcu_dereference_protected in order to prevent lockdep
> complaint.
>
> Found by Linux Driver Verification project (linuxtesting.org)
>
> Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
> ---
> drivers/net/macvtap.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 0737bd4..0f0f9ce 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -94,7 +94,8 @@ static int get_slot(struct macvlan_dev *vlan, struct macvtap_queue *q)
> int i;
>
> for (i = 0; i < MAX_MACVTAP_QUEUES; i++) {
> - if (rcu_dereference(vlan->taps[i]) == q)
> + if (rcu_dereference_protected(vlan->taps[i],
> + lockdep_is_held(&macvtap_lock)) == q)
And now it's too long. Maybe a temporary would be better?
struct macvtap_queue *t;
t = rcu_dereference_protected(vlan->taps[i],
lockdep_is_held(&macvtap_lock));
if (t == q)
return i;
?
Anyway -
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> return i;
> }
>
> --
> 1.7.7
^ permalink raw reply
* Re: [Question]About KVM network zero-copy feature!
From: Michael S. Tsirkin @ 2012-08-12 9:37 UTC (permalink / raw)
To: Robert Vineyard
Cc: xiaohui.xin, kvm, netdev, Peter Huang(Peng), virtualization, avi,
Stephen Hemminger
In-Reply-To: <5026FC04.6080108@tuffmail.com>
On Sat, Aug 11, 2012 at 08:42:44PM -0400, Robert Vineyard wrote:
> (adding Xin Xiaohui to the conversation for comment)
>
> According to the NetworkingTodo page on the KVM wiki, zero-copy RX
> for macvtap is in fact on the roadmap, assigned to Xin:
>
> http://www.linux-kvm.org/page/NetworkingTodo
AFAIK Xin left Intel and is not working on it.
Contributions are welcome.
> The Release Notes for RHEL 6.2 (originally published on 12/06/2011)
> also specifically mention macvtap/vhost zero-copy capabilities as
> being included as a Technology Preview:
>
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/6.2_Release_Notes/virtualization.html
>
> Since I've been unable to find much information on the current
> status of this development, can anyone confirm if this functionality
> is still in the works? If so, is there any planned ETA?
>
> Thanks,
> Robert Vineyard
I think this means TX.
--
MST
^ 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