headers
Jay Vosburgh | 1 Dec 2009 01:00
Picon
Favicon

Re: [PATCH net-next-2.6] bonding: allow arp_ip_targets to be on a separate vlan from bond device

Andy Gospodarek <andy <at> greyhouse.net> wrote:

>This allows a bond device to specify an arp_ip_target as a host that is
>not on the same vlan as the base bond device.  A configuration like
>this, now works:
>
>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
>    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>    inet 127.0.0.1/8 scope host lo
>    inet6 ::1/128 scope host
>       valid_lft forever preferred_lft forever
>2: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
>    link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
>3: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
>    link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
>8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
>    link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
>    inet6 fe80::213:21ff:febe:33e9/64 scope link
>       valid_lft forever preferred_lft forever
>9: bond0.100 <at> bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
>    link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
>    inet 10.0.100.2/24 brd 10.0.100.255 scope global bond0.100
>    inet6 fe80::213:21ff:febe:33e9/64 scope link
>       valid_lft forever preferred_lft forever

	I'm not quite clear here on exactly what it is that doesn't
work.

	Putting the arp_ip_target on a VLAN destination already works
(and has for a long time); I just checked against a 2.6.32-rc to make
(Continue reading)

Permalink | Reply | 18 comments |
headers
David Miller | 1 Dec 2009 01:21
Favicon

Re: Subject: [PATCH 3/6] bna: Brocade 10Gb Ethernet device driver

From: Debashis Dutt <ddutt <at> brocade.com>
Date: Thu, 26 Nov 2009 01:28:32 -0800

> +#define BNA_PAGE_SIZE	PAGE_SIZE
> +#define BNA_PAGE_SHIFT	PAGE_SHIFT
> +
> +#define BNA_ASSERT(x) BUG_ON(!(x))
> +
> +#define bna_dma_addr64(_x) cpu_to_be64((_x))
> +
> +#define bfa_addr_t 	char __iomem *
> +#define bfa_u32(__pa64)	((__pa64) >> 32)
> +
> +#define bfa_reg_read(_raddr)		readl(_raddr)
> +#define bfa_reg_write(_raddr, _val)	writel(_val, _raddr)
> +#define bfa_os_panic()

All of the definitions in this header file are inappropriate.

Use the standard types and interfaces the Linux kernel provides in the
actual source code.

I know what you're trying to do, but it's not appropriate.

You want a layer of abstract types and macros so you can compile the
same code in different environments and just swap out this one header
file and we've been trying to tell you over and over again that you
can't do that.

Also, the "version.h" file that contains just one macro definition is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Octavian Purdila | 1 Dec 2009 01:19
Favicon

[RFC] sk_nulls_next_rcu


I am trying to convert the LLC code to RCU, and it appears that for proc 
support a sk_nulls_next_rcu would be required. 

Is this the wrong way to do it, or is it that nobody need it yet?

Thanks,
tavi

 
diff --git a/include/net/sock.h b/include/net/sock.h
index 3f1a480..989d7e9 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
 <at>  <at>  -351,6 +351,13  <at>  <at>  static inline struct sock *sk_nulls_next(const struct sock *sk)
 		NULL;
 }

+static inline struct sock *sk_nulls_next_rcu(const struct sock *sk)
+{
+     struct hlist_nulls_node *n = rcu_dereference(sk->sk_nulls_node.next);
+     return !is_a_nulls(n) ? hlist_nulls_entry(n, struct sock, sk_nulls_node) :
+	    NULL;
+}
+
 static inline int sk_unhashed(const struct sock *sk)
 {
 	return hlist_unhashed(&sk->sk_node);

diff --git a/net/llc/llc_proc.c b/net/llc/llc_proc.c
(Continue reading)

Permalink | Reply | 5 comments |
headers
David Miller | 1 Dec 2009 01:24
Favicon

Re: [RFC] sk_nulls_next_rcu

From: Octavian Purdila <opurdila <at> ixiacom.com>
Date: Tue, 1 Dec 2009 02:19:29 +0200

> 
> I am trying to convert the LLC code to RCU, and it appears that for proc 
> support a sk_nulls_next_rcu would be required. 
> 
> Is this the wrong way to do it, or is it that nobody need it yet?

I think simply nobody needed it yet.

Eric, please take a look at Octavian's patch, thanks!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Michael Chan | 1 Dec 2009 01:17
Favicon

Re: [RFC PATCH 07/10] bnx2: remove skb_dma_map/unmap calls from driver

On Mon, 2009-11-30 at 02:26 -0800, Michael Chan wrote:
> It looks ok except in bnx2_free_tx_skbs()

Here's the slightly revised patch with some bug fixes.  Thanks again to
Alexander.

From: Alexander Duyck <alexander.h.duyck <at> intel.com>

Due to the fact that skb_dma_map/unmap do not work correctly when a HW
IOMMU is enabled it has been recommended to go about removing the calls
from the network device drivers.

[ Fix bnx2_free_tx_skbs() ring indexing and use NETDEV_TX_OK return
  code in bnx2_start_xmit() after cleaning up DMA mapping errors. -Mchan ]

Signed-off-by: Alexander Duyck <alexander.h.duyck <at> intel.com>
Signed-off-by: Michael Chan <mchan <at> broadcom.com>
---
 drivers/net/bnx2.c |   72 +++++++++++++++++++++++++++++++++++++++++++--------
 drivers/net/bnx2.h |    1 +
 2 files changed, 61 insertions(+), 12 deletions(-)

diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 539d23b..f47bf50 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
 <at>  <at>  -2815,13 +2815,21  <at>  <at>  bnx2_tx_int(struct bnx2 *bp, struct bnx2_napi *bnapi, int budget)
 			}
 		}
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Miller | 1 Dec 2009 01:34
Favicon

Re: [PATCH 0/20] Batch network namespace cleanup

From: ebiederm <at> xmission.com (Eric W. Biederman)
Date: Sun, 29 Nov 2009 17:46:03 -0800

> Recently Jamal and Daniel perform some experiments and found that
> large numbers of network namespace exiting simultaneously is very
> inefficient.  24+ minutes in some configurations.  The cpu overhead
> was negligible but it results in long hold times of net_mutex, and
> memory being consumed a long time after the last user has gone away.
> 
> I looked into it and discovered that by batching network namespace
> cleanups I can reduce the time for 4k network namespaces exiting from
> 5-7 minutes in my configuration to 44 seconds.
> 
> This patch series is my set of changes to the network namespace core
> and associated cleanups to allow for network namespace batching.

All applied, and assuming all of the build checks pass I'll
push this out to net-next-2.6

I should look into that inet_twsk_purge performance issue you mention
when tearing down a namespace.  It walks the entire hash table and
takes a lock for every hash chain.

Eric, is it possible for us to at least slightly optimize this by
doing a peek at whether the head pointer of each chain is NULL and
bypass the spinlock and everything else in that case?  Or is this
not legal with sk_nulls?

Something like:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Octavian Purdila | 1 Dec 2009 01:32
Favicon

Re: [RFC] sk_nulls_next_rcu

On Tuesday 01 December 2009 02:24:54 you wrote:
> From: Octavian Purdila <opurdila <at> ixiacom.com>
> Date: Tue, 1 Dec 2009 02:19:29 +0200
> 
> > I am trying to convert the LLC code to RCU, and it appears that for proc
> > support a sk_nulls_next_rcu would be required.
> >
> > Is this the wrong way to do it, or is it that nobody need it yet?
> 
> I think simply nobody needed it yet.
> 
> Eric, please take a look at Octavian's patch, thanks!
> 

I will send a patch series later with several LLC enhancements, no need to 
look over the LLC bits yet - its not all done yet. I'll CC Eric on the RCU 
parts :)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Eric W. Biederman | 1 Dec 2009 01:55
Favicon

Re: [PATCH 0/20] Batch network namespace cleanup

David Miller <davem <at> davemloft.net> writes:

> From: ebiederm <at> xmission.com (Eric W. Biederman)
> Date: Sun, 29 Nov 2009 17:46:03 -0800
>
>> Recently Jamal and Daniel perform some experiments and found that
>> large numbers of network namespace exiting simultaneously is very
>> inefficient.  24+ minutes in some configurations.  The cpu overhead
>> was negligible but it results in long hold times of net_mutex, and
>> memory being consumed a long time after the last user has gone away.
>> 
>> I looked into it and discovered that by batching network namespace
>> cleanups I can reduce the time for 4k network namespaces exiting from
>> 5-7 minutes in my configuration to 44 seconds.
>> 
>> This patch series is my set of changes to the network namespace core
>> and associated cleanups to allow for network namespace batching.
>
> All applied, and assuming all of the build checks pass I'll
> push this out to net-next-2.6
>
> I should look into that inet_twsk_purge performance issue you mention
> when tearing down a namespace.  It walks the entire hash table and
> takes a lock for every hash chain.
>
> Eric, is it possible for us to at least slightly optimize this by
> doing a peek at whether the head pointer of each chain is NULL and
> bypass the spinlock and everything else in that case?  Or is this
> not legal with sk_nulls?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Duyck, Alexander H | 1 Dec 2009 02:03
Picon
Favicon

RE: [RFC PATCH 00/10] Remove skb_dma_map/unmap calls

David Miller wrote:
> From: Alexander Duyck <alexander.h.duyck <at> intel.com>
> Date: Tue, 24 Nov 2009 17:20:12 -0800
> 
>> This patch series removes the skb_dma_map and skb_dma_unmap function
>> calls. The reason for this change is because the use of
>> skb_dma_map/unmap can lead to serious issues when HW IOMMU is
>> enabled.  This is because each mapping 
>> of the skb with a HW IOMMU enabled results in a new set of DMA
>> mappings. 
>> This in turn leads to issues when skbs are cloned for uses such as
>> bridging or pktgen because each transmitting device will update the
>> skb shared info structure resulting in some mappings being
>> overwritten, and others being freed multiple times. 
>> 
>> I am looking for input specifically on the tg3, be2net, and bnx2
>> driver patches as I am not very familiar with them and I am not
>> certain if additional changes are required.
>> 
>> I have included the changes for the Intel wired Ethernet drivers as a
>> reference.
> 
> These changes look good, but at least one of them does not apply
> to current net-2.6
> 
> Can you respin this against current sources?
> 
> Thanks a lot for doing this work Alexander.

Due to the fact that nobody else had reported the issue and it existed in previous kernel versions I figured
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andy Gospodarek | 1 Dec 2009 02:21
Gravatar

Re: [PATCH net-next-2.6] bonding: allow arp_ip_targets to be on a separate vlan from bond device

On Mon, Nov 30, 2009 at 04:00:38PM -0800, Jay Vosburgh wrote:
> Andy Gospodarek <andy <at> greyhouse.net> wrote:
> 
> >This allows a bond device to specify an arp_ip_target as a host that is
> >not on the same vlan as the base bond device.  A configuration like
> >this, now works:
> >
> >1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
> >    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> >    inet 127.0.0.1/8 scope host lo
> >    inet6 ::1/128 scope host
> >       valid_lft forever preferred_lft forever
> >2: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
> >    link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
> >3: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
> >    link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
> >8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
> >    link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
> >    inet6 fe80::213:21ff:febe:33e9/64 scope link
> >       valid_lft forever preferred_lft forever
> >9: bond0.100 <at> bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
> >    link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
> >    inet 10.0.100.2/24 brd 10.0.100.255 scope global bond0.100
> >    inet6 fe80::213:21ff:febe:33e9/64 scope link
> >       valid_lft forever preferred_lft forever
> 
> 	I'm not quite clear here on exactly what it is that doesn't
> work.
> 
> 	Putting the arp_ip_target on a VLAN destination already works
(Continue reading)

Permalink | Reply | 17 comments |

Gmane