* [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
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Michael S. Tsirkin @ 2012-08-12 10:22 UTC (permalink / raw)
To: Or Gerlitz
Cc: Eric W. Biederman, Or Gerlitz, davem, roland, netdev, ali,
sean.hefty, Erez Shitrit, Doug Ledford
In-Reply-To: <CAJZOPZKtdvxTGvrxj+T896mEexb=yN9s1cCuqUmhhzCOvUPEnA@mail.gmail.com>
On Wed, Aug 08, 2012 at 08:23:15AM +0300, Or Gerlitz wrote:
> On Sun, Aug 5, 2012 at 9:50 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> [...]
> > So it seems that a sane solution would involve an extra level of
> > indirection, with guest addresses being translated to host IB addresses.
> > As long as you do this, maybe using an ethernet frame format makes sense.
> [...]
>
> Yep, that's among the points we're trying to make, the way you've put
> it makes it clearer.
>
> > So far the things that make sense. Here are some that don't, to me:
>
> > - Is a pdf presentation all you have in terms of documentation?
> > We are talking communication protocols here - I would expect a
> > proper spec, and some effort to standardize, otherwise where's the
> > guarantee it won't change in an incompatible way?
>
> To be precise, the solution uses 100% IPoIB wire-protocol, so we don't
> see a need
> for any spec change / standardization effort.
Yes, I am guessing this is the real reason you pack LID/QPN
in the MAC - to make it all local. But it's a hack really,
and if you start storing it all in the SM you will need
to document the format so others can inter-operate.
> This might go to the 1st
> point you've
> brought... improve the documentation, will do that. The pdf you looked
> at was presented
> in a conference.
>
> > Other things that I would expect to be addressed in such a spec is
> > interaction with other IPoIB features, such as connected
> > mode, checksum offloading etc, and IB features such as multipath etc.
>
> For the eipoib interface, it doesn't really matters if the underlyind
> ipoib clones used by it (we call them VIFs) use connected or datagram
> mode, what does matter is the MTU and offload features supported by
> these VIFs, for which the eipoib interface will have the min among all
> these VIFs. Since for a given eipoib nic, all its VIFs must originated
> from the same IPoIB PIF (e.g ib0) its easy admin job to make sure they
> all have the same mtu / features which are needed for that eipoib nic,
> e.g by using the same mode (connected/datagram for all of them), hope
> this is clear.
>
Just pointing out all this needs to be documented.
> > - The way you encode LID/QPN in the MAC seems questionable. IIRC there's
> > more to IB addressing than just the LID. Since everyone on the subnet
> > need access to this translation, I think it makes sense to store it in
> > the SM. I think this would also obviate some IPv4 specific hacks in kernel.
>
> The idead beyond the encoding was uniqueness, LID/QPN is unique per IB
> HCA end-node.
But then it breaks with VM migration, IB failover, softmac setting in
guest, probably more?
> I wasn't sure to understand the comment re the IPv4 hacks.
This refers to the ARP hack that you use to fix
VM migration.
> > - IGMP/MAC snooping in a driver is just too hairy.
>
> mmm, any rough idea/direction how to do that otherwise?
Sure, even two ways, ideally you'd do both :)
A. fix macvtap
1. Use netdev_for_each_mc_addr etc to get multicast addresses
2. teach macvtap to fill that in (it currently floods multicasts
for guest to guest communication so we ned to fix it anyway)
B. fix bridge
teach bridge to work for VMs without using promisc mode
> > As you point out, bridge currently needs the uplink in promisc mode.
> > I don't think a driver should work around that limitation.
> > For some setups, it might be interesting to remove the
> > promisc mode requirement, failing that,
> > I think you could use macvtap passthrough.
>
> That's in the plans, the current code doesn't assume that the eipoib
> has bridge on top, for VM networking it works with bridge + tap,
> bridge + macvtap, but it would easily work with passthrough when we
> allow to create multiple eipoib interfaces on the same ipoib PIF (e.g
> today for the ib0 PIF we create eipoib eth0, and then two VIFs ib0.1
> and ib0.2 that are enslaved by eth0, but next we will create eth1 and
> eth2 which will use ib0.1 and ib0.2
> respectively.
The whole promisc mode emulation is there for the bridge, no?
Since you don't support promisc, ideally we'd check a hardware
capability and fail gracefully, though naturally this is not top
priority.
> > - Currently migration works without host kernel help, would be
> > preferable to keep it that way.
>
> OK
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Michael S. Tsirkin @ 2012-08-12 10:36 UTC (permalink / raw)
To: Or Gerlitz
Cc: Eric W. Biederman, Ali Ayoub, David Miller, ogerlitz, roland,
netdev, sean.hefty, erezsh, dledford
In-Reply-To: <CAJZOPZ+JKZAxF-SaWxCd_8pLqhrLXrPyQHEo0n-gNzuvMOA02w@mail.gmail.com>
On Thu, Aug 09, 2012 at 07:34:23AM +0300, Or Gerlitz wrote:
> > Infiniband is standard enough you could quite easily implement virtual
> > infiniband bridging as an alternative to ethernet bridging.
>
> Not really, as Michael indicated in his response over this thread
> http://marc.info/?l=linux-netdev&m=134419288218373&w=2
> IPoIB link layer addresses use IB HW constructs for which soft
> hardware address setting isn't supported, and this interferes
> with live migration.
>
> Or.
But I'd just like to point out your code does not support softmac
either.
--
MST
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Michael S. Tsirkin @ 2012-08-12 10:54 UTC (permalink / raw)
To: Or Gerlitz
Cc: Eric W. Biederman, Or Gerlitz, davem, roland, netdev, ali,
sean.hefty, Erez Shitrit, Doug Ledford
In-Reply-To: <CAJZOPZKtdvxTGvrxj+T896mEexb=yN9s1cCuqUmhhzCOvUPEnA@mail.gmail.com>
On Wed, Aug 08, 2012 at 08:23:15AM +0300, Or Gerlitz wrote:
> > So far the things that make sense. Here are some that don't, to me:
>
> > - Is a pdf presentation all you have in terms of documentation?
> > We are talking communication protocols here - I would expect a
> > proper spec, and some effort to standardize, otherwise where's the
> > guarantee it won't change in an incompatible way?
>
> To be precise, the solution uses 100% IPoIB wire-protocol, so we don't
> see a need
> for any spec change / standardization effort.
Thinking about it some more, the solution is not really 100% local:
- ARP packets used at migration are visible on the network
- QPN/LID in MAC are guest visible, and could be exported on the network
^ permalink raw reply
* Matter that needs your attention
From: Ooi, teek @ 2012-08-12 10:05 UTC (permalink / raw)
To: netdev
Good day,
This is a personal email directed to you for your consideration alone, I
request that it remain and be treated as such only. Please bear with me for
now and do not ask my name. I am a banker here in Malaysia
I have an interesting business proposal for you that will be of immense
benefit to both of us. Although this may be hard for you to believe, we
stand to gain 7.2 million USD between us in a matter of days. Please grant
me the benefit of doubt and hear me out. I need you to signify your interest
by replying to this email..
Most importantly, I will need you to promise to keep whatever you learn from
me between us even if you decide not to go along with me. I will make more
details available to you on receipt of a positive response from you.
Warm regards from
Malaysia
^ permalink raw reply
* Re: [PATCH V3] CS89x0 : Use ioread16/iowrite16 on all platforms
From: Domenico Andreoli @ 2012-08-12 11:24 UTC (permalink / raw)
To: David Miller
Cc: jaccon.bastiaansen, arnd, netdev, s.hauer, romieu, joe, gfm,
festevam, linux-arm-kernel
In-Reply-To: <20120517.190346.175685939436302276.davem@davemloft.net>
On Thu, May 17, 2012 at 07:03:46PM -0400, David Miller wrote:
> From: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
> Date: Thu, 17 May 2012 19:11:42 +0200
>
> > The use of the inw/outw functions by the cs89x0 platform driver
> > results in NULL pointer references on ARM platforms and
> > platforms that do not provide ISA-style programmed I/O accessors.
> >
> > Using inw/outw also accesses the wrong address space on platforms
> > that have a PCI I/O space that is not identity-mapped into the
> > physical address space.
> >
> > Signed-off-by: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
>
> I could nit-pick more on this patch, but it's such a significant
> improvement I'm just going to apply this V3 as-is to net-next.
Is this going into v3.6 or v3.7?
cheers,
Domenico
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Or Gerlitz @ 2012-08-12 13:09 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Eric W. Biederman, davem, roland, netdev, ali, sean.hefty,
Erez Shitrit, Doug Ledford
In-Reply-To: <20120812102240.GG1421@redhat.com>
On 12/08/2012 13:22, Michael S. Tsirkin wrote:
> On Wed, Aug 08, 2012 at 08:23:15AM +0300, Or Gerlitz wrote:
>> >On Sun, Aug 5, 2012 at 9:50 PM, Michael S. Tsirkin<mst@redhat.com> wrote:
>> >
>> >[...]
>>> > >So it seems that a sane solution would involve an extra level of
>>> > >indirection, with guest addresses being translated to host IB addresses.
>>> > >As long as you do this, maybe using an ethernet frame format makes sense.
>> >[...]
>> >
>> >Yep, that's among the points we're trying to make, the way you've put
>> >it makes it clearer.
>> >
>>> > >So far the things that make sense. Here are some that don't, to me:
>> >
>>> > >- Is a pdf presentation all you have in terms of documentation?
>>> > > We are talking communication protocols here - I would expect a
>>> > > proper spec, and some effort to standardize, otherwise where's the
>>> > > guarantee it won't change in an incompatible way?
>> >
>> >To be precise, the solution uses 100% IPoIB wire-protocol, so we don't
>> >see a need
>> >for any spec change / standardization effort.
> Yes, I am guessing this is the real reason you pack LID/QPN
> in the MAC - to make it all local. But it's a hack really,
> and if you start storing it all in the SM you will need
> to document the format so others can inter-operate.
I'd like to review the way we generate these MAC addresses, maybe it
can be done differently.
>
>
>> >This might go to the 1stpoint you've
>> >brought... improve the documentation, will do that. The pdf you looked
>> >at was presentedin a conference.
>>
>>> > > Other things that I would expect to be addressed in such a spec is
>>> > > interaction with other IPoIB features, such as connected
>>> > > mode, checksum offloading etc, and IB features such as multipath etc.
>> >
>> >For the eipoib interface, it doesn't really matters if the underlyind
>> >ipoib clones used by it (we call them VIFs) use connected or datagram
>> >mode, what does matter is the MTU and offload features supported by
>> >these VIFs, for which the eipoib interface will have the min among all
>> >these VIFs. Since for a given eipoib nic, all its VIFs must originated
>> >from the same IPoIB PIF (e.g ib0) its easy admin job to make sure they
>> >all have the same mtu / features which are needed for that eipoib nic,
>> >e.g by using the same mode (connected/datagram for all of them), hope
>> >this is clear.
>> >
> Just pointing out all this needs to be documented.
OK, will do
>
>
>>> > >- The way you encode LID/QPN in the MAC seems questionable. IIRC there's
>>> > > more to IB addressing than just the LID. Since everyone on the subnet
>>> > > need access to this translation, I think it makes sense to store it in
>>> > > the SM. I think this would also obviate some IPv4 specific hacks in kernel.
>> >
>> >The idead beyond the encoding was uniqueness, LID/QPN is unique per IB
>> >HCA end-node.
> But then it breaks with VM migration, IB failover, softmac setting in guest, probably more?
With the current design/code the remote mac of a VM changes, when that
VM migrates or IB
LIDs are changed. As for softmac setting in the guest, we don't send
the guest MAC on the wire
anyway, since the Ethernet header is removed.
Or.
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Or Gerlitz @ 2012-08-12 13:15 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Or Gerlitz, Eric W. Biederman, davem, roland, netdev, ali,
sean.hefty, Erez Shitrit, Doug Ledford
In-Reply-To: <20120812102240.GG1421@redhat.com>
On 12/08/2012 13:22, Michael S. Tsirkin wrote:
>>> >>- IGMP/MAC snooping in a driver is just too hairy.
>>
>> >mmm, any rough idea/direction how to do that otherwise?
> Sure, even two ways, ideally you'd do both:)
> A. fix macvtap
> 1. Use netdev_for_each_mc_addr etc to get multicast addresses
> 2. teach macvtap to fill that in (it currently floods multicasts
> for guest to guest communication so we ned to fix it anyway)
>
> B. fix bridge
> teach bridge to work for VMs without using promisc mode
I wasn't sure to fully follow... need some more bits of info, the
macvtap fix
relates only to IGMP snooping, correct? as for the bridge fix, does this
somehow
relates to ARP snooping we do in the driver? how?
Or.
^ 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