* Re: tun.c non formal header protocol?
From: Rémi Denis-Courmont @ 2011-02-24 19:04 UTC (permalink / raw)
To: Kfir Lavi; +Cc: netdev
In-Reply-To: <AANLkTikpkgiTRDJe0gxuXosp_uvg0gKM_c7GcvL+hhLm@mail.gmail.com>
Le jeudi 24 février 2011 20:37:32 Kfir Lavi, vous avez écrit :
> I would like to use custom protocol over tun/tap device.
Over TAP, you can only exchange Ethernet frames. However you can use whatever
network layer you like (so long as it has an Ethernet type associated).
Over TUN, you can exchange packets without any link layer header, for any
network layer protocol defined in Linux.
In principles, you can probably just use a (Ethernet) type that is not used by
any existing stack in the Linux kernel. But I don't see any point in doing so,
as the kernel will just drop the packets on the floor afterward.
> I'm grabbing packets, and changing them, to deliver via tap,
> to a listener that knows this custom protocol.
> The custom protocol is just wrapping the packet with another
> small header.
> Is it possible to move custom packets via tun.c ?
It's difficult to say without a clearer picture what you are trying to do.
--
Rémi Denis-Courmont
http://www.remlab.info/
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* via-rhine -- VT6105M and checksum offloading
From: Benjamin LaHaise @ 2011-02-24 18:58 UTC (permalink / raw)
To: netdev
Hi folks,
I've recently noticed that one of the embedded systems I'm using (the
PCEngines ALIXes) is becoming CPU bound under heavy network traffic.
Upon investigation, it looks like the VT6105M isn't actually using the
hardware checksum offloading support of the hardware. Are there any
known reasons why this isn't enabled (hardware bugs?)? I'll test enabling
it in the driver, but I figured it would be worth asking if this path
has been explored already. Cheers,
-ben
^ permalink raw reply
* Re: [PATCH] cxgb{3,4}: streamline Kconfig options
From: Dimitris Michailidis @ 2011-02-24 19:41 UTC (permalink / raw)
To: Jan Beulich; +Cc: David Miller, divy, linux-kbuild, netdev
In-Reply-To: <4D661E2702000078000336B5@vpn.id2.novell.com>
Jan Beulich wrote:
> As to that INET vs NET dependency - is it possible that the
> network drivers really just need NET, but the iSCSI ones need
> INET? In which case the only common dependency would be
> PCI - certainly not worth a custom helper option.
I see about a dozen network drivers that depend on INET. These may be the
result of cut&paste from other drivers' Kconfig entries rather than actual
dependencies. Also some of these drivers select or selected in the past
INET_LRO and that may have something to do with their INET dependency, not sure.
Reading the commit message that introduced CHELSIO_T3_DEPENDS, it talks of
hidden dependencies that select does not see. I am not sure which exactly
but since it's been a few years since that commit I'll try to see what the
situation is today without the *_DEPENDS symbols and let you know.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving peer configuration - ieee
From: Ben Hutchings @ 2011-02-24 19:42 UTC (permalink / raw)
To: Shmulik Ravid; +Cc: davem, John Fastabend, Eilon Greenstein, netdev
In-Reply-To: <1298581410.8877.21.camel@lb-tlvb-shmulik.il.broadcom.com>
On Thu, 2011-02-24 at 23:03 +0200, Shmulik Ravid wrote:
> These 2 patches add the support for retrieving the remote or peer DCBX
> configuration via dcbnl for embedded DCBX stacks. The peer configuration
> is part of the DCBX MIB and is useful for debugging and diagnostics of
> the overall DCB configuration. The first patch add this support for IEEE
> 802.1Qaz standard the second patch add the same support for the older
> CEE standard.
>
> Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
> ---
> include/linux/dcbnl.h | 38 ++++++++++++++++++++++++++
> include/net/dcbnl.h | 5 +++
> net/dcb/dcbnl.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 114 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
> index 4c5b26e..3102185 100644
> --- a/include/linux/dcbnl.h
> +++ b/include/linux/dcbnl.h
> @@ -110,6 +110,22 @@ struct dcb_app {
> __u16 protocol;
> };
>
> +/* This structure contains the APP feature information sent by the peer.
> + * It is used for both the IEEE 802.1Qaz and the CEE flavors.
> + *
> + * @willing: willing bit in the peer APP tlv
> + * @error: error bit in the peer APP tlv
> + * @app_count: The number of objects in the peer APP table.
[...]
It looks like this was supposed to be a kernel-doc comment, but it's not
valid as such unless you start with:
/**
* struct dcb_peer_app_info - one-line description here
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: via-rhine -- VT6105M and checksum offloading
From: David Miller @ 2011-02-24 20:23 UTC (permalink / raw)
To: bcrl; +Cc: netdev
In-Reply-To: <20110224185805.GI30393@kvack.org>
From: Benjamin LaHaise <bcrl@kvack.org>
Date: Thu, 24 Feb 2011 13:58:05 -0500
> I've recently noticed that one of the embedded systems I'm using (the
> PCEngines ALIXes) is becoming CPU bound under heavy network traffic.
> Upon investigation, it looks like the VT6105M isn't actually using the
> hardware checksum offloading support of the hardware. Are there any
> known reasons why this isn't enabled (hardware bugs?)? I'll test enabling
> it in the driver, but I figured it would be worth asking if this path
> has been explored already. Cheers,
As far as I can tell it was never attempted. So it should work.
If you do that, while you're here, you can make rhine_rx() take
a "napi" arg and make this driver use netif_gso_receive() too.
Don't forget to set NETIF_F_GRO or similar in netdev->flags during
probe, and also hookup the necessary ethtool hooks.
^ permalink raw reply
* [RFC] be2net: add rxhash support
From: Eric Dumazet @ 2011-02-24 20:24 UTC (permalink / raw)
To: Ajit Khaparde; +Cc: netdev
In-Reply-To: <1298560543.2814.4.camel@edumazet-laptop>
Ajit, it seems be2net provides RSS hash value in rx compl descriptor ?
Could we feed skb->rxhash with it ?
Thanks !
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 0bdccb1..f2db5b2 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1038,6 +1038,9 @@ static void be_rx_compl_process(struct be_adapter *adapter,
skb->truesize = skb->len + sizeof(struct sk_buff);
skb->protocol = eth_type_trans(skb, adapter->netdev);
+ if (adapter->netdev->features & NETIF_F_RXHASH)
+ skb->rxhash = AMAP_GET_BITS(struct amap_eth_rx_compl, rsshash, rxcp);
+
vlanf = AMAP_GET_BITS(struct amap_eth_rx_compl, vtp, rxcp);
vtm = AMAP_GET_BITS(struct amap_eth_rx_compl, vtm, rxcp);
@@ -1099,6 +1102,9 @@ static void be_rx_compl_process_gro(struct be_adapter *adapter,
return;
}
+ if (adapter->netdev->features & NETIF_F_RXHASH)
+ skb->rxhash = AMAP_GET_BITS(struct amap_eth_rx_compl, rsshash, rxcp);
+
remaining = pkt_size;
for (i = 0, j = -1; i < num_rcvd; i++) {
page_info = get_rx_page_info(adapter, rxo, rxq_idx);
@@ -2618,6 +2624,7 @@ static void be_netdev_init(struct net_device *netdev)
NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_FILTER |
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
NETIF_F_GRO | NETIF_F_TSO6;
+ netdev->features |= NETIF_F_RXHASH;
netdev->vlan_features |= NETIF_F_SG | NETIF_F_TSO |
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
^ permalink raw reply related
* Re: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving peer configuration - ieee
From: John Fastabend @ 2011-02-24 20:37 UTC (permalink / raw)
To: Shmulik Ravid
Cc: davem@davemloft.net, Eilon Greenstein, netdev@vger.kernel.org
In-Reply-To: <1298581410.8877.21.camel@lb-tlvb-shmulik.il.broadcom.com>
On 2/24/2011 1:03 PM, Shmulik Ravid wrote:
> These 2 patches add the support for retrieving the remote or peer DCBX
> configuration via dcbnl for embedded DCBX stacks. The peer configuration
> is part of the DCBX MIB and is useful for debugging and diagnostics of
> the overall DCB configuration. The first patch add this support for IEEE
> 802.1Qaz standard the second patch add the same support for the older
> CEE standard.
>
> Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
> ---
> include/linux/dcbnl.h | 38 ++++++++++++++++++++++++++
> include/net/dcbnl.h | 5 +++
> net/dcb/dcbnl.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 114 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
> index 4c5b26e..3102185 100644
> --- a/include/linux/dcbnl.h
> +++ b/include/linux/dcbnl.h
> @@ -110,6 +110,22 @@ struct dcb_app {
> __u16 protocol;
> };
>
> +/* This structure contains the APP feature information sent by the peer.
> + * It is used for both the IEEE 802.1Qaz and the CEE flavors.
> + *
> + * @willing: willing bit in the peer APP tlv
> + * @error: error bit in the peer APP tlv
> + * @app_count: The number of objects in the peer APP table.
> + *
> + * In addition to this information the full peer APP tlv also contains
> + * a table of 'app_count' APP objects defined above.
> + */
> +struct dcb_peer_app_info {
> + __u8 willing;
> + __u8 error;
> + __u16 app_count;
> +};
> +
The IEEE 802.1Qaz spec defines the APP TLV as informational
so there are no willing or error bits in this case. See
section D.2.12 of the 802.1Qaz draft.
Can we drop these fields or do they have some other meaning
here?
Thanks,
John.
^ permalink raw reply
* [PATCH] ipv4: Rearrange how ip_route_newports() gets port keys.
From: David Miller @ 2011-02-24 21:42 UTC (permalink / raw)
To: netdev
ip_route_newports() is the only place in the entire kernel that
cares about the port members in the routing cache entry's lookup
flow key.
Therefore the only reason we store an entire flow inside of the
struct rtentry is for this one special case.
Rewrite ip_route_newports() such that:
1) The caller passes in the original port values, so we don't need
to use the rth->fl.fl_ip_{s,d}port values to remember them.
2) The lookup flow is constructed by hand instead of being copied
from the routing cache entry's flow.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/route.h | 19 +++++++++++--------
net/dccp/ipv4.c | 10 +++++++---
net/ipv4/tcp_ipv4.c | 6 +++++-
3 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/include/net/route.h b/include/net/route.h
index bf790c1..b3f89ad 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -200,16 +200,19 @@ static inline int ip_route_connect(struct rtable **rp, __be32 dst,
}
static inline int ip_route_newports(struct rtable **rp, u8 protocol,
+ __be16 orig_sport, __be16 orig_dport,
__be16 sport, __be16 dport, struct sock *sk)
{
- if (sport != (*rp)->fl.fl_ip_sport ||
- dport != (*rp)->fl.fl_ip_dport) {
- struct flowi fl;
-
- memcpy(&fl, &(*rp)->fl, sizeof(fl));
- fl.fl_ip_sport = sport;
- fl.fl_ip_dport = dport;
- fl.proto = protocol;
+ if (sport != orig_sport || dport != orig_dport) {
+ struct flowi fl = { .oif = (*rp)->fl.oif,
+ .mark = (*rp)->fl.mark,
+ .fl4_dst = (*rp)->fl.fl4_dst,
+ .fl4_src = (*rp)->fl.fl4_src,
+ .fl4_tos = (*rp)->fl.fl4_tos,
+ .proto = (*rp)->fl.proto,
+ .fl_ip_sport = sport,
+ .fl_ip_dport = dport };
+
if (inet_sk(sk)->transparent)
fl.flags |= FLOWI_FLAG_ANYSRC;
if (protocol == IPPROTO_TCP)
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 45a434f..9379891 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -43,6 +43,7 @@ int dccp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
struct inet_sock *inet = inet_sk(sk);
struct dccp_sock *dp = dccp_sk(sk);
const struct sockaddr_in *usin = (struct sockaddr_in *)uaddr;
+ __be16 orig_sport, orig_dport;
struct rtable *rt;
__be32 daddr, nexthop;
int tmp;
@@ -63,10 +64,12 @@ int dccp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
nexthop = inet->opt->faddr;
}
+ orig_sport = inet->inet_sport;
+ orig_dport = usin->sin_port;
tmp = ip_route_connect(&rt, nexthop, inet->inet_saddr,
RT_CONN_FLAGS(sk), sk->sk_bound_dev_if,
IPPROTO_DCCP,
- inet->inet_sport, usin->sin_port, sk, 1);
+ orig_sport, orig_dport, sk, 1);
if (tmp < 0)
return tmp;
@@ -99,8 +102,9 @@ int dccp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
if (err != 0)
goto failure;
- err = ip_route_newports(&rt, IPPROTO_DCCP, inet->inet_sport,
- inet->inet_dport, sk);
+ err = ip_route_newports(&rt, IPPROTO_DCCP,
+ orig_sport, orig_dport,
+ inet->inet_sport, inet->inet_dport, sk);
if (err != 0)
goto failure;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index ef5a90b..27a0cc8 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -149,6 +149,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
struct inet_sock *inet = inet_sk(sk);
struct tcp_sock *tp = tcp_sk(sk);
struct sockaddr_in *usin = (struct sockaddr_in *)uaddr;
+ __be16 orig_sport, orig_dport;
struct rtable *rt;
__be32 daddr, nexthop;
int tmp;
@@ -167,10 +168,12 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
nexthop = inet->opt->faddr;
}
+ orig_sport = inet->inet_sport;
+ orig_dport = usin->sin_port;
tmp = ip_route_connect(&rt, nexthop, inet->inet_saddr,
RT_CONN_FLAGS(sk), sk->sk_bound_dev_if,
IPPROTO_TCP,
- inet->inet_sport, usin->sin_port, sk, 1);
+ orig_sport, orig_dport, sk, 1);
if (tmp < 0) {
if (tmp == -ENETUNREACH)
IP_INC_STATS_BH(sock_net(sk), IPSTATS_MIB_OUTNOROUTES);
@@ -234,6 +237,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
goto failure;
err = ip_route_newports(&rt, IPPROTO_TCP,
+ orig_sport, orig_dport,
inet->inet_sport, inet->inet_dport, sk);
if (err)
goto failure;
--
1.7.4.1
^ permalink raw reply related
* RE: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving peer configuration - ieee
From: Shmulik Ravid - Rabinovitz @ 2011-02-24 22:03 UTC (permalink / raw)
To: John Fastabend
Cc: davem@davemloft.net, Eilon Greenstein, netdev@vger.kernel.org
In-Reply-To: <4D66C186.7040409@intel.com>
> -----Original Message-----
> From: John Fastabend [mailto:john.r.fastabend@intel.com]
> Sent: Thursday, February 24, 2011 10:37 PM
> To: Shmulik Ravid - Rabinovitz
> Cc: davem@davemloft.net; Eilon Greenstein; netdev@vger.kernel.org
> Subject: Re: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving
> peer configuration - ieee
>
> On 2/24/2011 1:03 PM, Shmulik Ravid wrote:
> > These 2 patches add the support for retrieving the remote or peer
> DCBX
> > configuration via dcbnl for embedded DCBX stacks. The peer
> configuration
> > is part of the DCBX MIB and is useful for debugging and diagnostics
> of
> > the overall DCB configuration. The first patch add this support for
> IEEE
> > 802.1Qaz standard the second patch add the same support for the older
> > CEE standard.
> >
> > Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
> > ---
> > include/linux/dcbnl.h | 38 ++++++++++++++++++++++++++
> > include/net/dcbnl.h | 5 +++
> > net/dcb/dcbnl.c | 71
> +++++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 114 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
> > index 4c5b26e..3102185 100644
> > --- a/include/linux/dcbnl.h
> > +++ b/include/linux/dcbnl.h
> > @@ -110,6 +110,22 @@ struct dcb_app {
> > __u16 protocol;
> > };
> >
> > +/* This structure contains the APP feature information sent by the
> peer.
> > + * It is used for both the IEEE 802.1Qaz and the CEE flavors.
> > + *
> > + * @willing: willing bit in the peer APP tlv
> > + * @error: error bit in the peer APP tlv
> > + * @app_count: The number of objects in the peer APP table.
> > + *
> > + * In addition to this information the full peer APP tlv also
> contains
> > + * a table of 'app_count' APP objects defined above.
> > + */
> > +struct dcb_peer_app_info {
> > + __u8 willing;
> > + __u8 error;
> > + __u16 app_count;
> > +};
> > +
>
> The IEEE 802.1Qaz spec defines the APP TLV as informational
> so there are no willing or error bits in this case. See
> section D.2.12 of the 802.1Qaz draft.
>
> Can we drop these fields or do they have some other meaning
> here?
>
OK, They are part of the CEE APP tlv though.
I wanted to share this structure between the 802.1Qaz and CEE so
I'll have a single driver handler that retrieve the number of
peer apps. How about if we keep a single driver handler, but the
APP info will be exposed to the user only with the CEE flavor.
That is the PEER_APP attribute will be CEE specific ?
Shmulik
^ permalink raw reply
* RE: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving peer configuration - ieee
From: Shmulik Ravid - Rabinovitz @ 2011-02-24 22:04 UTC (permalink / raw)
To: Ben Hutchings
Cc: davem@davemloft.net, John Fastabend, Eilon Greenstein,
netdev@vger.kernel.org
In-Reply-To: <1298576559.2613.40.camel@bwh-desktop>
> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Thursday, February 24, 2011 9:43 PM
> To: Shmulik Ravid - Rabinovitz
> Cc: davem@davemloft.net; John Fastabend; Eilon Greenstein;
> netdev@vger.kernel.org
> Subject: Re: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving
> peer configuration - ieee
>
> On Thu, 2011-02-24 at 23:03 +0200, Shmulik Ravid wrote:
> > These 2 patches add the support for retrieving the remote or peer
> DCBX
> > configuration via dcbnl for embedded DCBX stacks. The peer
> configuration
> > is part of the DCBX MIB and is useful for debugging and diagnostics
> of
> > the overall DCB configuration. The first patch add this support for
> IEEE
> > 802.1Qaz standard the second patch add the same support for the older
> > CEE standard.
> >
> > Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
> > ---
> > include/linux/dcbnl.h | 38 ++++++++++++++++++++++++++
> > include/net/dcbnl.h | 5 +++
> > net/dcb/dcbnl.c | 71
> +++++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 114 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
> > index 4c5b26e..3102185 100644
> > --- a/include/linux/dcbnl.h
> > +++ b/include/linux/dcbnl.h
> > @@ -110,6 +110,22 @@ struct dcb_app {
> > __u16 protocol;
> > };
> >
> > +/* This structure contains the APP feature information sent by the
> peer.
> > + * It is used for both the IEEE 802.1Qaz and the CEE flavors.
> > + *
> > + * @willing: willing bit in the peer APP tlv
> > + * @error: error bit in the peer APP tlv
> > + * @app_count: The number of objects in the peer APP table.
> [...]
>
> It looks like this was supposed to be a kernel-doc comment, but it's
> not
> valid as such unless you start with:
>
> /**
> * struct dcb_peer_app_info - one-line description here
>
> Ben.
>
OK thanks, I'll fix this
Shmulik
^ permalink raw reply
* Re: [Bugme-new] [Bug 29712] New: Bonding Driver(version : 3.5.0) - Problem with ARP monitoring in active backup mode
From: Andrew Morton @ 2011-02-24 22:51 UTC (permalink / raw)
To: harsha.r02; +Cc: bugzilla-daemon, bugme-daemon, netdev, Jay Vosburgh
In-Reply-To: <bug-29712-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 23 Feb 2011 10:41:34 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=29712
>
> Summary: Bonding Driver(version : 3.5.0) - Problem with ARP
> monitoring in active backup mode
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.32
That's a paleolithic kernel you have there. This problem might have
been fixed already. Can you test a more recent kernel?
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: harsha.r02@mphasis.com
> Regression: No
>
>
> We are facing an issue with arp_monitoring in active_backup mode when
> two network interfaces of two systems are connected back to back (point
> to point connected without switch connection) and bond is created on
> either systems with point-to-point connected interfaces as slaves.
>
> Steps to reproduce :
>
> 1. Initially the bond was created with two interfaces eth2 and eth3, having
> eth2 as primary
>
> # modprobe bonding primary=eth2 mode=1 arp_interval=500
> arp_ip_target=192.168.4.61
>
> # ifconfig bond0 192.168.2.63 netmask 255.255.255.0
>
> # ifenslave bond0 eth2 eth3
>
> # ifconfig bond0 up
>
> # cat /proc/net/bonding/bond0
>
> Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
>
> Bonding Mode: fault-tolerance (active-backup)
>
> Primary Slave: eth2
> Currently Active Slave: eth2
> MII Status: up
> MII Polling Interval (ms): 0
> Up Delay (ms): 0
> Down Delay (ms): 0
> ARP Polling Interval (ms): 500
> ARP IP target/s (n.n.n.n form): 192.168.4.61
>
> Slave Interface: eth2
> MII Status: up
> Link Failure Count: 1
> Permanent HW addr: 00:26:55:27:88:52
>
> Slave Interface: eth3
> MII Status: down
> Link Failure Count: 1
> Permanent HW addr: 00:26:55:27:88:54
>
> 2. The primary interface was made down, and fail over happened
>
> # ifconfig down
>
> # cat /proc/net/bonding/bond0
>
> Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
>
> Bonding Mode: fault-tolerance (active-backup)
> Primary Slave: eth2
> Currently Active Slave: eth3 <-- As expected -->
> MII Status: up
> MII Polling Interval (ms): 0
> Up Delay (ms): 0
> Down Delay (ms): 0
> ARP Polling Interval (ms): 500
> ARP IP target/s (n.n.n.n form): 192.168.4.61
>
> Slave Interface: eth2
> MII Status: down
> Link Failure Count: 2
> Permanent HW addr: 00:26:55:27:88:52
>
> Slave Interface: eth3
> MII Status: up
> Link Failure Count: 1
> Permanent HW addr: 00:26:55:27:88:54
>
> 3. The primary interface was brought up again and we did not see failover
> happening back to primary
>
> ned1g6:~# ifconfig eth2 up
>
> ned1g6:~# cat /proc/net/bonding/bond0
>
> Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
>
> Bonding Mode: fault-tolerance (active-backup)
> Primary Slave: eth2
> Currently Active Slave: eth3 <-- Ideally this should have been eth2 -->
> MII Status: up
> MII Polling Interval (ms): 0
> Up Delay (ms): 0
> Down Delay (ms): 0
> ARP Polling Interval (ms): 500
> ARP IP target/s (n.n.n.n form): 192.168.4.61
>
> Slave Interface: eth2
> MII Status: down
> Link Failure Count: 2
> Permanent HW addr: 00:26:55:27:88:52
>
> Slave Interface: eth3
> MII Status: up
> Link Failure Count: 1
> Permanent HW addr: 00:26:55:27:88:54
>
> The problem is that when the primary_slave comes up from the down state
> it won't get selected as the currently active slave for the bond.
>
> Best Regards,
> Harsha
^ permalink raw reply
* Re: [net-next-2.6 0/7][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2011-02-25 0:29 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips
In-Reply-To: <1298545109-8990-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 24 Feb 2011 02:58:22 -0800
> The following series contains jumbo frame support for X540 devices,
> comment cleanup/fixes for ixgbevf & igb, and the addition of Tx rate
> limiting feature for igb.
>
> The following are changes since commit 55ae22d08fc9b531bc8a88b7306004e7053bb425:
> Merge branch 'tipc-Feb23-2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/net-next-2.6
>
> and are available in the git repository at:
> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6 master
Pulled, thanks a lot Jeff.
^ permalink raw reply
* Re: [PATCH ref0] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Po-Yu Chuang @ 2011-02-25 2:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus, davem,
Po-Yu Chuang
In-Reply-To: <1298569685.2814.16.camel@edumazet-laptop>
Hi Eric,
On Fri, Feb 25, 2011 at 1:48 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 24 février 2011 à 18:39 +0100, Eric Dumazet a écrit :
>> Le jeudi 24 février 2011 à 17:29 +0800, Po-Yu Chuang a écrit :
>> > From: Po-Yu Chuang <ratbert@faraday-tech.com>
>> > +
>> > +static bool ftmac100_rx_packet(struct ftmac100 *priv, int *processed)
>> > +{
>> > + struct net_device *netdev = priv->netdev;
>> > + struct ftmac100_rxdes *rxdes;
>> > + struct sk_buff *skb;
>> > + struct page *page;
>> > + dma_addr_t map;
>> > + int length;
>> > +
>> > + rxdes = ftmac100_rx_locate_first_segment(priv);
>> > + if (!rxdes)
>> > + return false;
>> > +
>> > + if (unlikely(ftmac100_rx_packet_error(priv, rxdes))) {
>> > + ftmac100_rx_drop_packet(priv);
>> > + return true;
>> > + }
>> > +
>> > + /*
>> > + * It is impossible to get multi-segment packets
>> > + * because we always provide big enough receive buffers.
>> > + */
>> > + if (unlikely(!ftmac100_rxdes_last_segment(rxdes)))
>> > + BUG();
>> > +
>> > + /* start processing */
>> > + skb = netdev_alloc_skb_ip_align(netdev, ETH_HLEN);
>>
>> Oh I see... You should allocate a bigger head (say... 128 bytes)
>>
>> And copy in it up to 128 bytes of first part... this to avoid upper
>> stack to reallocate skb head (because IP/TCP processing need to get
>> their headers in skb head)
>
> Take a look at drivers/net/niu.c :
>
> #define RX_SKB_ALLOC_SIZE 128 + NET_IP_ALIGN
>
> static int niu_process_rx_pkt(...)
> {
> ...
> skb = netdev_alloc_skb(np->dev, RX_SKB_ALLOC_SIZE);
> ...
> while (1) {
> ...
> niu_rx_skb_append(skb, page, off, append_size);
> }
> }
Oh I got it.
I will try this and redo the benchmarking.
Thanks,
Po-Yu Chuang
^ permalink raw reply
* [PATCH 2/3] ipvs: use enum to instead of magic numbers
From: Simon Horman @ 2011-02-25 2:43 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Changli Gao, Wensong Zhang, Julian Anastasov, Patrick McHardy,
Simon Horman
In-Reply-To: <1298601812-8168-1-git-send-email-horms@verge.net.au>
From: Changli Gao <xiaosuo@gmail.com>
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_xmit.c | 41 +++++++++++++++++++++++++-------------
1 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
index 1f2a4e3..a48239a 100644
--- a/net/netfilter/ipvs/ip_vs_xmit.c
+++ b/net/netfilter/ipvs/ip_vs_xmit.c
@@ -43,6 +43,13 @@
#include <net/ip_vs.h>
+enum {
+ IP_VS_RT_MODE_LOCAL = 1, /* Allow local dest */
+ IP_VS_RT_MODE_NON_LOCAL = 2, /* Allow non-local dest */
+ IP_VS_RT_MODE_RDR = 4, /* Allow redirect from remote daddr to
+ * local
+ */
+};
/*
* Destination cache to speed up outgoing route lookup
@@ -77,11 +84,7 @@ __ip_vs_dst_check(struct ip_vs_dest *dest, u32 rtos)
return dst;
}
-/*
- * Get route to destination or remote server
- * rt_mode: flags, &1=Allow local dest, &2=Allow non-local dest,
- * &4=Allow redirect from remote daddr to local
- */
+/* Get route to destination or remote server */
static struct rtable *
__ip_vs_get_out_rt(struct sk_buff *skb, struct ip_vs_dest *dest,
__be32 daddr, u32 rtos, int rt_mode)
@@ -126,15 +129,16 @@ __ip_vs_get_out_rt(struct sk_buff *skb, struct ip_vs_dest *dest,
}
local = rt->rt_flags & RTCF_LOCAL;
- if (!((local ? 1 : 2) & rt_mode)) {
+ if (!((local ? IP_VS_RT_MODE_LOCAL : IP_VS_RT_MODE_NON_LOCAL) &
+ rt_mode)) {
IP_VS_DBG_RL("Stopping traffic to %s address, dest: %pI4\n",
(rt->rt_flags & RTCF_LOCAL) ?
"local":"non-local", &rt->rt_dst);
ip_rt_put(rt);
return NULL;
}
- if (local && !(rt_mode & 4) && !((ort = skb_rtable(skb)) &&
- ort->rt_flags & RTCF_LOCAL)) {
+ if (local && !(rt_mode & IP_VS_RT_MODE_RDR) &&
+ !((ort = skb_rtable(skb)) && ort->rt_flags & RTCF_LOCAL)) {
IP_VS_DBG_RL("Redirect from non-local address %pI4 to local "
"requires NAT method, dest: %pI4\n",
&ip_hdr(skb)->daddr, &rt->rt_dst);
@@ -383,8 +387,8 @@ ip_vs_bypass_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,
EnterFunction(10);
- if (!(rt = __ip_vs_get_out_rt(skb, NULL, iph->daddr,
- RT_TOS(iph->tos), 2)))
+ if (!(rt = __ip_vs_get_out_rt(skb, NULL, iph->daddr, RT_TOS(iph->tos),
+ IP_VS_RT_MODE_NON_LOCAL)))
goto tx_error_icmp;
/* MTU checking */
@@ -512,7 +516,10 @@ ip_vs_nat_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,
}
if (!(rt = __ip_vs_get_out_rt(skb, cp->dest, cp->daddr.ip,
- RT_TOS(iph->tos), 1|2|4)))
+ RT_TOS(iph->tos),
+ IP_VS_RT_MODE_LOCAL |
+ IP_VS_RT_MODE_NON_LOCAL |
+ IP_VS_RT_MODE_RDR)))
goto tx_error_icmp;
local = rt->rt_flags & RTCF_LOCAL;
/*
@@ -755,7 +762,8 @@ ip_vs_tunnel_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,
EnterFunction(10);
if (!(rt = __ip_vs_get_out_rt(skb, cp->dest, cp->daddr.ip,
- RT_TOS(tos), 1|2)))
+ RT_TOS(tos), IP_VS_RT_MODE_LOCAL |
+ IP_VS_RT_MODE_NON_LOCAL)))
goto tx_error_icmp;
if (rt->rt_flags & RTCF_LOCAL) {
ip_rt_put(rt);
@@ -984,7 +992,9 @@ ip_vs_dr_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,
EnterFunction(10);
if (!(rt = __ip_vs_get_out_rt(skb, cp->dest, cp->daddr.ip,
- RT_TOS(iph->tos), 1|2)))
+ RT_TOS(iph->tos),
+ IP_VS_RT_MODE_LOCAL |
+ IP_VS_RT_MODE_NON_LOCAL)))
goto tx_error_icmp;
if (rt->rt_flags & RTCF_LOCAL) {
ip_rt_put(rt);
@@ -1128,7 +1138,10 @@ ip_vs_icmp_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,
*/
if (!(rt = __ip_vs_get_out_rt(skb, cp->dest, cp->daddr.ip,
- RT_TOS(ip_hdr(skb)->tos), 1|2|4)))
+ RT_TOS(ip_hdr(skb)->tos),
+ IP_VS_RT_MODE_LOCAL |
+ IP_VS_RT_MODE_NON_LOCAL |
+ IP_VS_RT_MODE_RDR)))
goto tx_error_icmp;
local = rt->rt_flags & RTCF_LOCAL;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/3] ipvs: unify the formula to estimate the overhead of processing connections
From: Simon Horman @ 2011-02-25 2:43 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Changli Gao, Wensong Zhang, Julian Anastasov, Patrick McHardy,
Simon Horman
In-Reply-To: <1298601812-8168-1-git-send-email-horms@verge.net.au>
From: Changli Gao <xiaosuo@gmail.com>
lc and wlc use the same formula, but lblc and lblcr use another one. There
is no reason for using two different formulas for the lc variants.
The formula used by lc is used by all the lc variants in this patch.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Acked-by: Wensong Zhang <wensong@linux-vs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
include/net/ip_vs.h | 14 ++++++++++++++
net/netfilter/ipvs/ip_vs_lblc.c | 13 +++----------
net/netfilter/ipvs/ip_vs_lblcr.c | 25 +++++++------------------
net/netfilter/ipvs/ip_vs_lc.c | 18 +-----------------
net/netfilter/ipvs/ip_vs_wlc.c | 20 ++------------------
5 files changed, 27 insertions(+), 63 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 17b01b2..e74da41e 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -1243,6 +1243,20 @@ static inline void ip_vs_conn_drop_conntrack(struct ip_vs_conn *cp)
/* CONFIG_IP_VS_NFCT */
#endif
+static inline unsigned int
+ip_vs_dest_conn_overhead(struct ip_vs_dest *dest)
+{
+ /*
+ * We think the overhead of processing active connections is 256
+ * times higher than that of inactive connections in average. (This
+ * 256 times might not be accurate, we will change it later) We
+ * use the following formula to estimate the overhead now:
+ * dest->activeconns*256 + dest->inactconns
+ */
+ return (atomic_read(&dest->activeconns) << 8) +
+ atomic_read(&dest->inactconns);
+}
+
#endif /* __KERNEL__ */
#endif /* _NET_IP_VS_H */
diff --git a/net/netfilter/ipvs/ip_vs_lblc.c b/net/netfilter/ipvs/ip_vs_lblc.c
index 4a9c8cd..6bf7a80 100644
--- a/net/netfilter/ipvs/ip_vs_lblc.c
+++ b/net/netfilter/ipvs/ip_vs_lblc.c
@@ -389,12 +389,7 @@ __ip_vs_lblc_schedule(struct ip_vs_service *svc)
int loh, doh;
/*
- * We think the overhead of processing active connections is fifty
- * times higher than that of inactive connections in average. (This
- * fifty times might not be accurate, we will change it later.) We
- * use the following formula to estimate the overhead:
- * dest->activeconns*50 + dest->inactconns
- * and the load:
+ * We use the following formula to estimate the load:
* (dest overhead) / dest->weight
*
* Remember -- no floats in kernel mode!!!
@@ -410,8 +405,7 @@ __ip_vs_lblc_schedule(struct ip_vs_service *svc)
continue;
if (atomic_read(&dest->weight) > 0) {
least = dest;
- loh = atomic_read(&least->activeconns) * 50
- + atomic_read(&least->inactconns);
+ loh = ip_vs_dest_conn_overhead(least);
goto nextstage;
}
}
@@ -425,8 +419,7 @@ __ip_vs_lblc_schedule(struct ip_vs_service *svc)
if (dest->flags & IP_VS_DEST_F_OVERLOAD)
continue;
- doh = atomic_read(&dest->activeconns) * 50
- + atomic_read(&dest->inactconns);
+ doh = ip_vs_dest_conn_overhead(dest);
if (loh * atomic_read(&dest->weight) >
doh * atomic_read(&least->weight)) {
least = dest;
diff --git a/net/netfilter/ipvs/ip_vs_lblcr.c b/net/netfilter/ipvs/ip_vs_lblcr.c
index bd329b1..0063176 100644
--- a/net/netfilter/ipvs/ip_vs_lblcr.c
+++ b/net/netfilter/ipvs/ip_vs_lblcr.c
@@ -178,8 +178,7 @@ static inline struct ip_vs_dest *ip_vs_dest_set_min(struct ip_vs_dest_set *set)
if ((atomic_read(&least->weight) > 0)
&& (least->flags & IP_VS_DEST_F_AVAILABLE)) {
- loh = atomic_read(&least->activeconns) * 50
- + atomic_read(&least->inactconns);
+ loh = ip_vs_dest_conn_overhead(least);
goto nextstage;
}
}
@@ -192,8 +191,7 @@ static inline struct ip_vs_dest *ip_vs_dest_set_min(struct ip_vs_dest_set *set)
if (dest->flags & IP_VS_DEST_F_OVERLOAD)
continue;
- doh = atomic_read(&dest->activeconns) * 50
- + atomic_read(&dest->inactconns);
+ doh = ip_vs_dest_conn_overhead(dest);
if ((loh * atomic_read(&dest->weight) >
doh * atomic_read(&least->weight))
&& (dest->flags & IP_VS_DEST_F_AVAILABLE)) {
@@ -228,8 +226,7 @@ static inline struct ip_vs_dest *ip_vs_dest_set_max(struct ip_vs_dest_set *set)
list_for_each_entry(e, &set->list, list) {
most = e->dest;
if (atomic_read(&most->weight) > 0) {
- moh = atomic_read(&most->activeconns) * 50
- + atomic_read(&most->inactconns);
+ moh = ip_vs_dest_conn_overhead(most);
goto nextstage;
}
}
@@ -239,8 +236,7 @@ static inline struct ip_vs_dest *ip_vs_dest_set_max(struct ip_vs_dest_set *set)
nextstage:
list_for_each_entry(e, &set->list, list) {
dest = e->dest;
- doh = atomic_read(&dest->activeconns) * 50
- + atomic_read(&dest->inactconns);
+ doh = ip_vs_dest_conn_overhead(dest);
/* moh/mw < doh/dw ==> moh*dw < doh*mw, where mw,dw>0 */
if ((moh * atomic_read(&dest->weight) <
doh * atomic_read(&most->weight))
@@ -563,12 +559,7 @@ __ip_vs_lblcr_schedule(struct ip_vs_service *svc)
int loh, doh;
/*
- * We think the overhead of processing active connections is fifty
- * times higher than that of inactive connections in average. (This
- * fifty times might not be accurate, we will change it later.) We
- * use the following formula to estimate the overhead:
- * dest->activeconns*50 + dest->inactconns
- * and the load:
+ * We use the following formula to estimate the load:
* (dest overhead) / dest->weight
*
* Remember -- no floats in kernel mode!!!
@@ -585,8 +576,7 @@ __ip_vs_lblcr_schedule(struct ip_vs_service *svc)
if (atomic_read(&dest->weight) > 0) {
least = dest;
- loh = atomic_read(&least->activeconns) * 50
- + atomic_read(&least->inactconns);
+ loh = ip_vs_dest_conn_overhead(least);
goto nextstage;
}
}
@@ -600,8 +590,7 @@ __ip_vs_lblcr_schedule(struct ip_vs_service *svc)
if (dest->flags & IP_VS_DEST_F_OVERLOAD)
continue;
- doh = atomic_read(&dest->activeconns) * 50
- + atomic_read(&dest->inactconns);
+ doh = ip_vs_dest_conn_overhead(dest);
if (loh * atomic_read(&dest->weight) >
doh * atomic_read(&least->weight)) {
least = dest;
diff --git a/net/netfilter/ipvs/ip_vs_lc.c b/net/netfilter/ipvs/ip_vs_lc.c
index 6063800..f391819 100644
--- a/net/netfilter/ipvs/ip_vs_lc.c
+++ b/net/netfilter/ipvs/ip_vs_lc.c
@@ -22,22 +22,6 @@
#include <net/ip_vs.h>
-
-static inline unsigned int
-ip_vs_lc_dest_overhead(struct ip_vs_dest *dest)
-{
- /*
- * We think the overhead of processing active connections is 256
- * times higher than that of inactive connections in average. (This
- * 256 times might not be accurate, we will change it later) We
- * use the following formula to estimate the overhead now:
- * dest->activeconns*256 + dest->inactconns
- */
- return (atomic_read(&dest->activeconns) << 8) +
- atomic_read(&dest->inactconns);
-}
-
-
/*
* Least Connection scheduling
*/
@@ -62,7 +46,7 @@ ip_vs_lc_schedule(struct ip_vs_service *svc, const struct sk_buff *skb)
if ((dest->flags & IP_VS_DEST_F_OVERLOAD) ||
atomic_read(&dest->weight) == 0)
continue;
- doh = ip_vs_lc_dest_overhead(dest);
+ doh = ip_vs_dest_conn_overhead(dest);
if (!least || doh < loh) {
least = dest;
loh = doh;
diff --git a/net/netfilter/ipvs/ip_vs_wlc.c b/net/netfilter/ipvs/ip_vs_wlc.c
index fdf0f58..bc1bfc4 100644
--- a/net/netfilter/ipvs/ip_vs_wlc.c
+++ b/net/netfilter/ipvs/ip_vs_wlc.c
@@ -27,22 +27,6 @@
#include <net/ip_vs.h>
-
-static inline unsigned int
-ip_vs_wlc_dest_overhead(struct ip_vs_dest *dest)
-{
- /*
- * We think the overhead of processing active connections is 256
- * times higher than that of inactive connections in average. (This
- * 256 times might not be accurate, we will change it later) We
- * use the following formula to estimate the overhead now:
- * dest->activeconns*256 + dest->inactconns
- */
- return (atomic_read(&dest->activeconns) << 8) +
- atomic_read(&dest->inactconns);
-}
-
-
/*
* Weighted Least Connection scheduling
*/
@@ -71,7 +55,7 @@ ip_vs_wlc_schedule(struct ip_vs_service *svc, const struct sk_buff *skb)
if (!(dest->flags & IP_VS_DEST_F_OVERLOAD) &&
atomic_read(&dest->weight) > 0) {
least = dest;
- loh = ip_vs_wlc_dest_overhead(least);
+ loh = ip_vs_dest_conn_overhead(least);
goto nextstage;
}
}
@@ -85,7 +69,7 @@ ip_vs_wlc_schedule(struct ip_vs_service *svc, const struct sk_buff *skb)
list_for_each_entry_continue(dest, &svc->destinations, n_list) {
if (dest->flags & IP_VS_DEST_F_OVERLOAD)
continue;
- doh = ip_vs_wlc_dest_overhead(dest);
+ doh = ip_vs_dest_conn_overhead(dest);
if (loh * atomic_read(&dest->weight) >
doh * atomic_read(&least->weight)) {
least = dest;
--
1.7.2.3
^ permalink raw reply related
* [GIT PULL nf-next-2.6] IPVS
From: Simon Horman @ 2011-02-25 2:43 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Changli Gao, Wensong Zhang, Julian Anastasov, Patrick McHardy,
Simon Horman
Hi Patrick,
please consider pulling
git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git master
go get the following changes by Changli.
ipvs: use hlist instead of list
ipvs: use enum to instead of magic numbers
ipvs: unify the formula to estimate the overhead of processing connections
include/net/ip_vs.h | 16 +++++++++++-
net/netfilter/ipvs/ip_vs_conn.c | 52 +++++++++++++++++++++----------------
net/netfilter/ipvs/ip_vs_lblc.c | 13 ++-------
net/netfilter/ipvs/ip_vs_lblcr.c | 25 +++++-------------
net/netfilter/ipvs/ip_vs_lc.c | 18 +------------
net/netfilter/ipvs/ip_vs_wlc.c | 20 +-------------
net/netfilter/ipvs/ip_vs_xmit.c | 41 +++++++++++++++++++----------
7 files changed, 84 insertions(+), 101 deletions(-)
^ permalink raw reply
* [PATCH 1/3] ipvs: use hlist instead of list
From: Simon Horman @ 2011-02-25 2:43 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Changli Gao, Wensong Zhang, Julian Anastasov, Patrick McHardy,
Simon Horman
In-Reply-To: <1298601812-8168-1-git-send-email-horms@verge.net.au>
From: Changli Gao <xiaosuo@gmail.com>
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
include/net/ip_vs.h | 2 +-
net/netfilter/ipvs/ip_vs_conn.c | 52 +++++++++++++++++++++-----------------
2 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 9399549..17b01b2 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -494,7 +494,7 @@ struct ip_vs_conn_param {
* IP_VS structure allocated for each dynamically scheduled connection
*/
struct ip_vs_conn {
- struct list_head c_list; /* hashed list heads */
+ struct hlist_node c_list; /* hashed list heads */
#ifdef CONFIG_NET_NS
struct net *net; /* Name space */
#endif
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index 83233fe..9c2a517 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -59,7 +59,7 @@ static int ip_vs_conn_tab_mask __read_mostly;
/*
* Connection hash table: for input and output packets lookups of IPVS
*/
-static struct list_head *ip_vs_conn_tab __read_mostly;
+static struct hlist_head *ip_vs_conn_tab __read_mostly;
/* SLAB cache for IPVS connections */
static struct kmem_cache *ip_vs_conn_cachep __read_mostly;
@@ -201,7 +201,7 @@ static inline int ip_vs_conn_hash(struct ip_vs_conn *cp)
spin_lock(&cp->lock);
if (!(cp->flags & IP_VS_CONN_F_HASHED)) {
- list_add(&cp->c_list, &ip_vs_conn_tab[hash]);
+ hlist_add_head(&cp->c_list, &ip_vs_conn_tab[hash]);
cp->flags |= IP_VS_CONN_F_HASHED;
atomic_inc(&cp->refcnt);
ret = 1;
@@ -234,7 +234,7 @@ static inline int ip_vs_conn_unhash(struct ip_vs_conn *cp)
spin_lock(&cp->lock);
if (cp->flags & IP_VS_CONN_F_HASHED) {
- list_del(&cp->c_list);
+ hlist_del(&cp->c_list);
cp->flags &= ~IP_VS_CONN_F_HASHED;
atomic_dec(&cp->refcnt);
ret = 1;
@@ -259,12 +259,13 @@ __ip_vs_conn_in_get(const struct ip_vs_conn_param *p)
{
unsigned hash;
struct ip_vs_conn *cp;
+ struct hlist_node *n;
hash = ip_vs_conn_hashkey_param(p, false);
ct_read_lock(hash);
- list_for_each_entry(cp, &ip_vs_conn_tab[hash], c_list) {
+ hlist_for_each_entry(cp, n, &ip_vs_conn_tab[hash], c_list) {
if (cp->af == p->af &&
p->cport == cp->cport && p->vport == cp->vport &&
ip_vs_addr_equal(p->af, p->caddr, &cp->caddr) &&
@@ -345,12 +346,13 @@ struct ip_vs_conn *ip_vs_ct_in_get(const struct ip_vs_conn_param *p)
{
unsigned hash;
struct ip_vs_conn *cp;
+ struct hlist_node *n;
hash = ip_vs_conn_hashkey_param(p, false);
ct_read_lock(hash);
- list_for_each_entry(cp, &ip_vs_conn_tab[hash], c_list) {
+ hlist_for_each_entry(cp, n, &ip_vs_conn_tab[hash], c_list) {
if (!ip_vs_conn_net_eq(cp, p->net))
continue;
if (p->pe_data && p->pe->ct_match) {
@@ -394,6 +396,7 @@ struct ip_vs_conn *ip_vs_conn_out_get(const struct ip_vs_conn_param *p)
{
unsigned hash;
struct ip_vs_conn *cp, *ret=NULL;
+ struct hlist_node *n;
/*
* Check for "full" addressed entries
@@ -402,7 +405,7 @@ struct ip_vs_conn *ip_vs_conn_out_get(const struct ip_vs_conn_param *p)
ct_read_lock(hash);
- list_for_each_entry(cp, &ip_vs_conn_tab[hash], c_list) {
+ hlist_for_each_entry(cp, n, &ip_vs_conn_tab[hash], c_list) {
if (cp->af == p->af &&
p->vport == cp->cport && p->cport == cp->dport &&
ip_vs_addr_equal(p->af, p->vaddr, &cp->caddr) &&
@@ -818,7 +821,7 @@ ip_vs_conn_new(const struct ip_vs_conn_param *p,
return NULL;
}
- INIT_LIST_HEAD(&cp->c_list);
+ INIT_HLIST_NODE(&cp->c_list);
setup_timer(&cp->timer, ip_vs_conn_expire, (unsigned long)cp);
ip_vs_conn_net_set(cp, p->net);
cp->af = p->af;
@@ -894,8 +897,8 @@ ip_vs_conn_new(const struct ip_vs_conn_param *p,
*/
#ifdef CONFIG_PROC_FS
struct ip_vs_iter_state {
- struct seq_net_private p;
- struct list_head *l;
+ struct seq_net_private p;
+ struct hlist_head *l;
};
static void *ip_vs_conn_array(struct seq_file *seq, loff_t pos)
@@ -903,13 +906,14 @@ static void *ip_vs_conn_array(struct seq_file *seq, loff_t pos)
int idx;
struct ip_vs_conn *cp;
struct ip_vs_iter_state *iter = seq->private;
+ struct hlist_node *n;
for (idx = 0; idx < ip_vs_conn_tab_size; idx++) {
ct_read_lock_bh(idx);
- list_for_each_entry(cp, &ip_vs_conn_tab[idx], c_list) {
+ hlist_for_each_entry(cp, n, &ip_vs_conn_tab[idx], c_list) {
if (pos-- == 0) {
iter->l = &ip_vs_conn_tab[idx];
- return cp;
+ return cp;
}
}
ct_read_unlock_bh(idx);
@@ -930,7 +934,8 @@ static void *ip_vs_conn_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
struct ip_vs_conn *cp = v;
struct ip_vs_iter_state *iter = seq->private;
- struct list_head *e, *l = iter->l;
+ struct hlist_node *e;
+ struct hlist_head *l = iter->l;
int idx;
++*pos;
@@ -938,15 +943,15 @@ static void *ip_vs_conn_seq_next(struct seq_file *seq, void *v, loff_t *pos)
return ip_vs_conn_array(seq, 0);
/* more on same hash chain? */
- if ((e = cp->c_list.next) != l)
- return list_entry(e, struct ip_vs_conn, c_list);
+ if ((e = cp->c_list.next))
+ return hlist_entry(e, struct ip_vs_conn, c_list);
idx = l - ip_vs_conn_tab;
ct_read_unlock_bh(idx);
while (++idx < ip_vs_conn_tab_size) {
ct_read_lock_bh(idx);
- list_for_each_entry(cp, &ip_vs_conn_tab[idx], c_list) {
+ hlist_for_each_entry(cp, e, &ip_vs_conn_tab[idx], c_list) {
iter->l = &ip_vs_conn_tab[idx];
return cp;
}
@@ -959,7 +964,7 @@ static void *ip_vs_conn_seq_next(struct seq_file *seq, void *v, loff_t *pos)
static void ip_vs_conn_seq_stop(struct seq_file *seq, void *v)
{
struct ip_vs_iter_state *iter = seq->private;
- struct list_head *l = iter->l;
+ struct hlist_head *l = iter->l;
if (l)
ct_read_unlock_bh(l - ip_vs_conn_tab);
@@ -1148,13 +1153,14 @@ void ip_vs_random_dropentry(struct net *net)
*/
for (idx = 0; idx < (ip_vs_conn_tab_size>>5); idx++) {
unsigned hash = net_random() & ip_vs_conn_tab_mask;
+ struct hlist_node *n;
/*
* Lock is actually needed in this loop.
*/
ct_write_lock_bh(hash);
- list_for_each_entry(cp, &ip_vs_conn_tab[hash], c_list) {
+ hlist_for_each_entry(cp, n, &ip_vs_conn_tab[hash], c_list) {
if (cp->flags & IP_VS_CONN_F_TEMPLATE)
/* connection template */
continue;
@@ -1202,12 +1208,14 @@ static void ip_vs_conn_flush(struct net *net)
flush_again:
for (idx = 0; idx < ip_vs_conn_tab_size; idx++) {
+ struct hlist_node *n;
+
/*
* Lock is actually needed in this loop.
*/
ct_write_lock_bh(idx);
- list_for_each_entry(cp, &ip_vs_conn_tab[idx], c_list) {
+ hlist_for_each_entry(cp, n, &ip_vs_conn_tab[idx], c_list) {
if (!ip_vs_conn_net_eq(cp, net))
continue;
IP_VS_DBG(4, "del connection\n");
@@ -1265,8 +1273,7 @@ int __init ip_vs_conn_init(void)
/*
* Allocate the connection hash table and initialize its list heads
*/
- ip_vs_conn_tab = vmalloc(ip_vs_conn_tab_size *
- sizeof(struct list_head));
+ ip_vs_conn_tab = vmalloc(ip_vs_conn_tab_size * sizeof(*ip_vs_conn_tab));
if (!ip_vs_conn_tab)
return -ENOMEM;
@@ -1286,9 +1293,8 @@ int __init ip_vs_conn_init(void)
IP_VS_DBG(0, "Each connection entry needs %Zd bytes at least\n",
sizeof(struct ip_vs_conn));
- for (idx = 0; idx < ip_vs_conn_tab_size; idx++) {
- INIT_LIST_HEAD(&ip_vs_conn_tab[idx]);
- }
+ for (idx = 0; idx < ip_vs_conn_tab_size; idx++)
+ INIT_HLIST_HEAD(&ip_vs_conn_tab[idx]);
for (idx = 0; idx < CT_LOCKARRAY_SIZE; idx++) {
rwlock_init(&__ip_vs_conntbl_lock_array[idx].l);
--
1.7.2.3
^ permalink raw reply related
* Please i wait to hear from you urgently, it very important
From: Ian Davies @ 2011-02-24 19:39 UTC (permalink / raw)
I am Ian Davies ;an accredited vendor of Alliot Groups, a subsidiary firm of Emirates International Holding (EIH); A private equity funds holding company that focuses on hedge funds.
I have contacted you in the hope that you can be my associate by accepting to stand as the legal recipient to a Fixed-Income deposit, valued at 25MUSD by provind an International Offshore account to clear the funds.
Once I file your details as the new recipient to the funds, the fundswill be approved through the AUTOMATED CLEARING HOUSE (ACH) - A facility used by financial institutions to distribute electronic debit and credit entries to bank accounts and therefore settles such entries. Under the automated clearing house system.
upon approval of your details as the new recipient; a Credit advice will be issued in your favor and the funds will clear in your account within three banking days. I am willing to give you 40% which is 10MUSD as your commission out of the 25MUSD for your assistance in providing an International Offshore account to clear the funds.
I am confident you will be honest enough to adhere to our agreed commissions in spite of the 25MUSD coming through your account. I will need you to forward me your legal names address and phone to file your details on the fund as the new recipient in this first Quater of the financial fiscal year 2011.
Looking forward to working with you.
Ian Davies
Accredited vendor
Alliot Groups PS
^ permalink raw reply
* Re: [Bugme-new] [Bug 29712] New: Bonding Driver(version : 3.5.0) - Problem with ARP monitoring in active backup mode
From: Brian Haley @ 2011-02-25 3:42 UTC (permalink / raw)
To: Andrew Morton
Cc: harsha.r02, bugzilla-daemon, bugme-daemon, netdev, Jay Vosburgh
In-Reply-To: <20110224145129.f366b59e.akpm@linux-foundation.org>
On 02/24/2011 05:51 PM, Andrew Morton wrote:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Wed, 23 Feb 2011 10:41:34 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=29712
>>
>> Summary: Bonding Driver(version : 3.5.0) - Problem with ARP
>> monitoring in active backup mode
>> Product: Drivers
>> Version: 2.5
>> Kernel Version: 2.6.32
>
> That's a paleolithic kernel you have there. This problem might have
> been fixed already. Can you test a more recent kernel?
I can add some more info since I originally looked at the problem. This
happens on 2.6.38 as well, and on this 2.6.32 kernel with a backported
3.7.0 bonding driver (with the primary_reselect option). Harsha has a
prototype patch that's being tested, but wanted to log the bug to see
if one of the bonding maintainers had a better solution.
I'll let him respond as I'm now out of the loop...
Thanks,
-Brian
^ permalink raw reply
* [PATCH net-next-2.6] sch_choke: add choke_skb_cb
From: Eric Dumazet @ 2011-02-25 3:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Stephen Hemminger, Patrick McHardy
Better document choke skb->cb[] use, like we did in netem and sfb
This adds a compile time check to make sure we dont exhaust skb->cb[]
space.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Stephen Hemminger <shemminger@vyatta.com>
CC: Patrick McHardy <kaber@trash.net>
---
net/sched/sch_choke.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
index ee1e209..06afbae 100644
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -219,14 +219,25 @@ static bool choke_match_flow(struct sk_buff *skb1,
return *ports1 == *ports2;
}
+struct choke_skb_cb {
+ u16 classid;
+};
+
+static inline struct choke_skb_cb *choke_skb_cb(const struct sk_buff *skb)
+{
+ BUILD_BUG_ON(sizeof(skb->cb) <
+ sizeof(struct qdisc_skb_cb) + sizeof(struct choke_skb_cb));
+ return (struct choke_skb_cb *)qdisc_skb_cb(skb)->data;
+}
+
static inline void choke_set_classid(struct sk_buff *skb, u16 classid)
{
- *(unsigned int *)(qdisc_skb_cb(skb)->data) = classid;
+ choke_skb_cb(skb)->classid = classid;
}
static u16 choke_get_classid(const struct sk_buff *skb)
{
- return *(unsigned int *)(qdisc_skb_cb(skb)->data);
+ return choke_skb_cb(skb)->classid;
}
/*
^ permalink raw reply related
* Re: [PATCH net-next-2.6] sch_choke: add choke_skb_cb
From: Stephen Hemminger @ 2011-02-25 3:48 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Patrick McHardy
In-Reply-To: <1298605541.2659.18.camel@edumazet-laptop>
On Fri, 25 Feb 2011 04:45:41 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Better document choke skb->cb[] use, like we did in netem and sfb
>
> This adds a compile time check to make sure we dont exhaust skb->cb[]
> space.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Stephen Hemminger <shemminger@vyatta.com>
> CC: Patrick McHardy <kaber@trash.net>
> ---
> net/sched/sch_choke.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
> index ee1e209..06afbae 100644
> --- a/net/sched/sch_choke.c
> +++ b/net/sched/sch_choke.c
> @@ -219,14 +219,25 @@ static bool choke_match_flow(struct sk_buff *skb1,
> return *ports1 == *ports2;
> }
>
> +struct choke_skb_cb {
> + u16 classid;
> +};
> +
> +static inline struct choke_skb_cb *choke_skb_cb(const struct sk_buff *skb)
> +{
> + BUILD_BUG_ON(sizeof(skb->cb) <
> + sizeof(struct qdisc_skb_cb) + sizeof(struct choke_skb_cb));
> + return (struct choke_skb_cb *)qdisc_skb_cb(skb)->data;
> +}
> +
> static inline void choke_set_classid(struct sk_buff *skb, u16 classid)
> {
> - *(unsigned int *)(qdisc_skb_cb(skb)->data) = classid;
> + choke_skb_cb(skb)->classid = classid;
> }
>
> static u16 choke_get_classid(const struct sk_buff *skb)
> {
> - return *(unsigned int *)(qdisc_skb_cb(skb)->data);
> + return choke_skb_cb(skb)->classid;
> }
>
Ideally class id should be u32, but then that would mean changing TC
classifier id and that is hardwired into the API.
--
^ permalink raw reply
* Re: [PATCH net-next-2.6] sch_choke: add choke_skb_cb
From: Eric Dumazet @ 2011-02-25 3:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev, Patrick McHardy
In-Reply-To: <20110224194812.6f96424d@nehalam>
Le jeudi 24 février 2011 à 19:48 -0800, Stephen Hemminger a écrit :
> Ideally class id should be u32, but then that would mean changing TC
> classifier id and that is hardwired into the API.
>
>
Yes, this is a bit disappointing, especially if we want to use rxhash
from external classifier (same problem for SFQ)
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving peer configuration - ieee
From: John Fastabend @ 2011-02-25 4:58 UTC (permalink / raw)
To: Shmulik Ravid - Rabinovitz
Cc: davem@davemloft.net, Eilon Greenstein, netdev@vger.kernel.org
In-Reply-To: <A31CB8AA22AA1E44B81563BEDB2C187812203E0F8C@SJEXCHCCR01.corp.ad.broadcom.com>
On 2/24/2011 2:03 PM, Shmulik Ravid - Rabinovitz wrote:
>> -----Original Message-----
>> From: John Fastabend [mailto:john.r.fastabend@intel.com]
>> Sent: Thursday, February 24, 2011 10:37 PM
>> To: Shmulik Ravid - Rabinovitz
>> Cc: davem@davemloft.net; Eilon Greenstein; netdev@vger.kernel.org
>> Subject: Re: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving
>> peer configuration - ieee
>>
>> On 2/24/2011 1:03 PM, Shmulik Ravid wrote:
>>> These 2 patches add the support for retrieving the remote or peer
>> DCBX
>>> configuration via dcbnl for embedded DCBX stacks. The peer
>> configuration
>>> is part of the DCBX MIB and is useful for debugging and diagnostics
>> of
>>> the overall DCB configuration. The first patch add this support for
>> IEEE
>>> 802.1Qaz standard the second patch add the same support for the older
>>> CEE standard.
>>>
>>> Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
>>> ---
>>> include/linux/dcbnl.h | 38 ++++++++++++++++++++++++++
>>> include/net/dcbnl.h | 5 +++
>>> net/dcb/dcbnl.c | 71
>> +++++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 114 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
>>> index 4c5b26e..3102185 100644
>>> --- a/include/linux/dcbnl.h
>>> +++ b/include/linux/dcbnl.h
>>> @@ -110,6 +110,22 @@ struct dcb_app {
>>> __u16 protocol;
>>> };
>>>
>>> +/* This structure contains the APP feature information sent by the
>> peer.
>>> + * It is used for both the IEEE 802.1Qaz and the CEE flavors.
>>> + *
>>> + * @willing: willing bit in the peer APP tlv
>>> + * @error: error bit in the peer APP tlv
>>> + * @app_count: The number of objects in the peer APP table.
>>> + *
>>> + * In addition to this information the full peer APP tlv also
>> contains
>>> + * a table of 'app_count' APP objects defined above.
>>> + */
>>> +struct dcb_peer_app_info {
>>> + __u8 willing;
>>> + __u8 error;
>>> + __u16 app_count;
>>> +};
>>> +
>>
>> The IEEE 802.1Qaz spec defines the APP TLV as informational
>> so there are no willing or error bits in this case. See
>> section D.2.12 of the 802.1Qaz draft.
>>
>> Can we drop these fields or do they have some other meaning
>> here?
>>
> OK, They are part of the CEE APP tlv though.
> I wanted to share this structure between the 802.1Qaz and CEE so
> I'll have a single driver handler that retrieve the number of
> peer apps. How about if we keep a single driver handler, but the
> APP info will be exposed to the user only with the CEE flavor.
> That is the PEER_APP attribute will be CEE specific ?
>
> Shmulik
>
That seems fine to me. Either don't expose the struct as you
suggested or zero the fields while in IEEE mode.
John.
^ permalink raw reply
* [PATCH] sysctl: ipv6: use correct net in ipv6_sysctl_rtcache_flush
From: Lucian Adrian Grijincu @ 2011-02-25 5:48 UTC (permalink / raw)
To: netdev, David S . Miller, Daniel Lezcano, Benjamin Thery
Cc: Lucian Adrian Grijincu
Before this patch issuing these commands:
fd = open("/proc/sys/net/ipv6/route/flush")
unshare(CLONE_NEWNET)
write(fd, "stuff")
would flush the newly created net, not the original one.
The equivalent ipv4 code is correct (stores the net inside ->extra1).
---
net/ipv6/route.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index f786aed..522563e 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2604,14 +2604,16 @@ static
int ipv6_sysctl_rtcache_flush(ctl_table *ctl, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
- struct net *net = current->nsproxy->net_ns;
- int delay = net->ipv6.sysctl.flush_delay;
- if (write) {
- proc_dointvec(ctl, write, buffer, lenp, ppos);
- fib6_run_gc(delay <= 0 ? ~0UL : (unsigned long)delay, net);
- return 0;
- } else
+ struct net *net;
+ int delay;
+ if (!write)
return -EINVAL;
+
+ net = (struct net *)ctl->extra1;
+ delay = net->ipv6.sysctl.flush_delay;
+ proc_dointvec(ctl, write, buffer, lenp, ppos);
+ fib6_run_gc(delay <= 0 ? ~0UL : (unsigned long)delay, net);
+ return 0;
}
ctl_table ipv6_route_table_template[] = {
@@ -2698,6 +2700,7 @@ struct ctl_table * __net_init ipv6_route_sysctl_init(struct net *net)
if (table) {
table[0].data = &net->ipv6.sysctl.flush_delay;
+ table[0].extra1 = net;
table[1].data = &net->ipv6.ip6_dst_ops.gc_thresh;
table[2].data = &net->ipv6.sysctl.ip6_rt_max_size;
table[3].data = &net->ipv6.sysctl.ip6_rt_gc_min_interval;
--
1.7.4.rc1.7.g2cf08.dirty
^ permalink raw reply related
* Re: [PATCH net-next-2.6] sch_choke: add choke_skb_cb
From: David Miller @ 2011-02-25 6:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, shemminger, kaber
In-Reply-To: <1298605541.2659.18.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 25 Feb 2011 04:45:41 +0100
> Better document choke skb->cb[] use, like we did in netem and sfb
>
> This adds a compile time check to make sure we dont exhaust skb->cb[]
> space.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Stephen Hemminger <shemminger@vyatta.com>
> CC: Patrick McHardy <kaber@trash.net>
Applied.
^ 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