* Re: IPv6: race condition in __ipv6_ifa_notify() and dst_free() ?
From: Jiri Bohac @ 2010-04-21 21:34 UTC (permalink / raw)
To: Hideaki YOSHIFUJI, Herbert Xu; +Cc: netdev, David Miller, Stephen Hemminger
In-Reply-To: <20100420174401.GB1334@midget.suse.cz>
Hi,
On Tue, Apr 20, 2010 at 07:44:01PM +0200, Jiri Bohac wrote:
> What is the reason __ipv6_ifa_notify() calls dst_free() when
> ip6_del_rt() fails? I don't see a way ip6_del_rt() could fail
> with the dst still needing to be freed.
checked again and I still think that if ip6_del_rt() fails,
ifp->rt must have been freed already. Anybody with a
counterexample?
> I am just testing whether the following will help:
>
> --- a/net/ipv6/addrconf.c 2010-04-17 00:12:32.000000000 +0200
> +++ b/net/ipv6/addrconf.c 2010-04-20 19:07:35.000000000 +0200
> @@ -3974,8 +3974,7 @@ static void __ipv6_ifa_notify(int event,
> addrconf_leave_anycast(ifp);
> addrconf_leave_solict(ifp->idev, &ifp->addr);
> dst_hold(&ifp->rt->u.dst);
> - if (ip6_del_rt(ifp->rt))
> - dst_free(&ifp->rt->u.dst);
> + ip6_del_rt(ifp->rt);
> break;
> }
> }
not surprisingly, it helps my case -- the race condition does not
happen and the resulting oopses disappears. Of course, this does
not prove the patch is correct.
Could anybody with more insight into the dst refcounting please
take a look? The code originally came from:
Author: Hideaki Yoshifuji <yoshfuji@linux-ipv6.org>
Date: Wed Aug 18 05:25:16 2004 +0900
[IPV6] refer inet6 device via corresponding local route from address structure.
And has been modified later by:
commit 4641e7a334adf6856300a98e7296dfc886c446af
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Feb 2 16:55:45 2006 -0800
[IPV6]: Don't hold extra ref count in ipv6_ifa_notify
Thanks,
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply
* Re: [PATCH] gianfar: Wait for both RX and TX to stop
From: David Miller @ 2010-04-21 21:33 UTC (permalink / raw)
To: galak; +Cc: timur.tabi, afleming, netdev
In-Reply-To: <CD8C73BA-0E18-4F85-A90B-C2FA5FFC8689@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Wed, 21 Apr 2010 14:13:00 -0500
> I'm not opposed, I'm just asking if we are saying we shouldn't be using cpu_relax() for spinning on HW status registers ever.
>
> If we are suggesting that cpu_relax() shouldn't be used in these scenarios going forward I'm ok w/the change you suggest and starting to convert other cpu_relax() calls to use spin_event_timeout()
Kumar this isn't an either-or thing.
In both cases we're using cpu_relax().
But by using spin_event_timeout() you're getting both the cpu_relax()
and a break-out in case the hardware gets wedged for some reason.
^ permalink raw reply
* Re: ipv6: Fix tcp_v6_send_response checksum
From: David Miller @ 2010-04-21 21:28 UTC (permalink / raw)
To: herbert; +Cc: netdev, cratiu
In-Reply-To: <20100421130920.GA31300@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 21 Apr 2010 21:09:20 +0800
> On Wed, Apr 21, 2010 at 01:58:23AM -0700, David Miller wrote:
>>
>> If we're going to use CHECKSUM_PARTIAL for these things (which we are
>> since commit 2e8e18ef52e7dd1af0a3bd1f7d990a1d0b249586 "tcp: Set
>> CHECKSUM_UNNECESSARY in tcp_init_nondata_skb"), we can't be setting
>> buff->csum as we always have been here in tcp_v6_send_response. We
>> need to leave it at zero.
>>
>> Kill that line and checksums are good again.
>>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> That line is needed for the CHECKSUM_NONE case. In fact, if we're
> in the CHECKSUM_PARTIAL case, then that buff->csum calculation
> should be a noop because it immediately gets overwritten when we
> subsequently set csum_start/csum_offset.
Ok, but the checksums were broken. Can you see why?
I think we changed semantics here when we did this:
- t1->check = csum_ipv6_magic(&fl.fl6_src, &fl.fl6_dst,
- tot_len, IPPROTO_TCP,
- buff->csum);
+ __tcp_v6_send_check(buff, &fl.fl6_src, &fl.fl6_dst);
which changes what ->csum needs to be. It used to need to be computed
over the header as well as any data afterwards, but now it has to
cover only data. Because now it evaluates to:
th->check = tcp_v6_check(skb->len, saddr, daddr,
csum_partial(th, th->doff << 2,
skb->csum));
See? We were computing the checksum over the TCP header twice now :-)
That's why my patch fixed things for dataless packets, whose
->csum would evaluate to zero.
So to make things work fully as-is, we would need to compute ->csum
over the post-header data only.
But an even easier change is to just be consistent with the rest
of the TCP packet generation code and use CHECKSUM_PARTIAL here.
And that's how I'll fix this.
What confused me here last night is the fact that CHECKSUM_NONE
is zero and the implicit zero initialization of new SKBs givs us
that :-)
Anyways, thanks for pointing this out!
^ permalink raw reply
* Re: [net-next,1/2] add iovnl netlink support
From: Arnd Bergmann @ 2010-04-21 21:22 UTC (permalink / raw)
To: Scott Feldman; +Cc: davem, netdev, chrisw
In-Reply-To: <201004201548.26609.arnd@arndb.de>
On Tuesday 20 April 2010, Arnd Bergmann wrote:
> > + * @IOV_ATTR_IFNAME: interface name of master (PF) net device (NLA_NUL_STRING)
> > + * @IOV_ATTR_VF_IFNAME: interface name of target VF device (NLA_NUL_STRING)
>
> As mentioned above, why not drop one of these, and just pass the VF's IFNAME?
>
Coming back to this point, I now think it would be ideal if we could actually
leave out IOV_ATTR_VF_IFNAME and just pass the master IFNAME and the slave
MAC address. Since we're not actually doing anything with the slave itself
but really talking the switch, it should not be needed at all.
That would solve all problems with the slave having moved to another namespace
already, and make it totally clear that this is not about configuring the
slave but about registering it.
Scott, would that still work with your driver?
Arnd
^ permalink raw reply
* Re: [net-next,1/2] add iovnl netlink support
From: Arnd Bergmann @ 2010-04-21 21:13 UTC (permalink / raw)
To: Scott Feldman; +Cc: Chris Wright, davem, netdev
In-Reply-To: <C7F4AD4F.2A34D%scofeldm@cisco.com>
On Wednesday 21 April 2010, Scott Feldman wrote:
> On 4/21/10 12:39 PM, "Arnd Bergmann" <arnd@arndb.de> wrote:
>
> >>> 1. Setting up the slave device
> >>> a) create an SR-IOV VF to assign to a guest
> >>> b) create a macvtap device to pass to qemu or vhost
> >>> c) attach a tap device to a bridge
> >>> d) create a macvlan device and put it into a container
> >>> e) create a virtual interface for a VMDq adapter
> >>
> >> OK, but iovnl isn't doing this.
> >
> > The set_mac_vlan that Scott's patch adds seems to implement 1a), as far
> > as I can tell. Interestingly, this is not actually implemented in
> > the enic driver in patch 2/2. So if we all agree that this is out of the
> > scope of iovnl, let's just remove it from the interface and find another
> > way for it (ethtool, iplink, ..., as listed above).
>
> You're right, not needed for enic since mac addr is included with
> port-profile push and vlan membership is implied by port-profile. So I put
> set_mac_vlan in there basically to elicit feedback.
Ok. Two points though:
- when you say that the mac address is included in the port-profile push,
does that imply that the VF does not have a mac address prior to this?
This would again mix the NIC configuration phase with the switch
association, which I think we really need to avoid if we want to be
able to implement the association in user space!
- The VLAN ID being implied in the port profile seems to be another
difference between what enic is doing and the current draft VDP
that will eventually become 802.1Qbg, and I fear that this difference
will be visible in the iovnl protocol.
> There really wouldn't be much different between iplink and iovnl since
> they're both rtnetlink...seems we should keep IOV-related APIs in one place.
> Maybe there are other IOV APIs to add to iovnl in the future like:
>
> vf <- add_vf(pf)
> del_vf(pf, vf)
>
> Ethtool doesn't seem the right place for this.
Right. My preference would probably be make these a subcategory of
the if_link, and use the existing RTM_NEWLINK/RTM_DELLINK commands.
This would make it resemble the existing interfaces and mean you can
use
ip link add link eth0 type macvlan # for a container
ip link add link eth0 type macvtap # for qemu/vhost
ip link add link eth0 type vf # for device assignment
There are obviously significant differences between these three, but
they also share enough of their properties to let us treat them
in similar ways.
If we integrate the iovnl client into iproute2, the sequence for setting
up an enic VF and associating it to the port profile could be
# create vf0, pass mac and vlan id to HW, no association yet
ip link add link eth0 name vf0 type vf mac fe:dc:ba:12:34:56 vlan 78
# associate vf with port profile, mac address must match the one assigned
# to the interface before.
ip iov assoc eth0 port-profile "general" host-uuid "dcf2a873-f5ee-41dd-a7ad-802a544e48c2" \
mac fe:dc:ba:12:34:56
Arnd
^ permalink raw reply
* [PATCH net-next-2.6] rps: immediate send IPI in process_backlog()
From: Eric Dumazet @ 2010-04-21 21:04 UTC (permalink / raw)
To: David Miller; +Cc: Tom Herbert, Changli Gao, netdev
If some skb are queued to our backlog, we are delaying IPI sending at
the end of net_rx_action(), increasing latencies. This defeats the
queueing, since we want to quickly dispatch packets to the pool of
worker cpus, then eventually deeply process our packets.
It's better to send IPI before processing our packets in upper layers,
from process_backlog().
Change the _and_disable_irq suffix to _and_enable_irq(), since we enable
local irq in net_rps_action(), sorry for the confusion.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
net/core/dev.c | 76 +++++++++++++++++++++++++----------------------
1 file changed, 42 insertions(+), 34 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index b31d5d6..9871660 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3239,11 +3239,48 @@ gro_result_t napi_gro_frags(struct napi_struct *napi)
}
EXPORT_SYMBOL(napi_gro_frags);
+/*
+ * net_rps_action sends any pending IPI's for rps.
+ * Note: called with local irq disabled, but exits with local irq enabled.
+ */
+static void net_rps_action_and_irq_enable(struct softnet_data *sd)
+{
+#ifdef CONFIG_RPS
+ struct softnet_data *remsd = sd->rps_ipi_list;
+
+ if (remsd) {
+ sd->rps_ipi_list = NULL;
+
+ local_irq_enable();
+
+ /* Send pending IPI's to kick RPS processing on remote cpus. */
+ while (remsd) {
+ struct softnet_data *next = remsd->rps_ipi_next;
+
+ if (cpu_online(remsd->cpu))
+ __smp_call_function_single(remsd->cpu,
+ &remsd->csd, 0);
+ remsd = next;
+ }
+ } else
+#endif
+ local_irq_enable();
+}
+
static int process_backlog(struct napi_struct *napi, int quota)
{
int work = 0;
struct softnet_data *sd = &__get_cpu_var(softnet_data);
+#ifdef CONFIG_RPS
+ /* Check if we have pending ipi, its better to send them now,
+ * not waiting net_rx_action() end.
+ */
+ if (sd->rps_ipi_list) {
+ local_irq_disable();
+ net_rps_action_and_irq_enable(sd);
+ }
+#endif
napi->weight = weight_p;
do {
struct sk_buff *skb;
@@ -3350,45 +3387,16 @@ void netif_napi_del(struct napi_struct *napi)
}
EXPORT_SYMBOL(netif_napi_del);
-/*
- * net_rps_action sends any pending IPI's for rps.
- * Note: called with local irq disabled, but exits with local irq enabled.
- */
-static void net_rps_action_and_irq_disable(void)
-{
-#ifdef CONFIG_RPS
- struct softnet_data *sd = &__get_cpu_var(softnet_data);
- struct softnet_data *remsd = sd->rps_ipi_list;
-
- if (remsd) {
- sd->rps_ipi_list = NULL;
-
- local_irq_enable();
-
- /* Send pending IPI's to kick RPS processing on remote cpus. */
- while (remsd) {
- struct softnet_data *next = remsd->rps_ipi_next;
-
- if (cpu_online(remsd->cpu))
- __smp_call_function_single(remsd->cpu,
- &remsd->csd, 0);
- remsd = next;
- }
- } else
-#endif
- local_irq_enable();
-}
-
static void net_rx_action(struct softirq_action *h)
{
- struct list_head *list = &__get_cpu_var(softnet_data).poll_list;
+ struct softnet_data *sd = &__get_cpu_var(softnet_data);
unsigned long time_limit = jiffies + 2;
int budget = netdev_budget;
void *have;
local_irq_disable();
- while (!list_empty(list)) {
+ while (!list_empty(&sd->poll_list)) {
struct napi_struct *n;
int work, weight;
@@ -3406,7 +3414,7 @@ static void net_rx_action(struct softirq_action *h)
* entries to the tail of this list, and only ->poll()
* calls can remove this head entry from the list.
*/
- n = list_first_entry(list, struct napi_struct, poll_list);
+ n = list_first_entry(&sd->poll_list, struct napi_struct, poll_list);
have = netpoll_poll_lock(n);
@@ -3441,13 +3449,13 @@ static void net_rx_action(struct softirq_action *h)
napi_complete(n);
local_irq_disable();
} else
- list_move_tail(&n->poll_list, list);
+ list_move_tail(&n->poll_list, &sd->poll_list);
}
netpoll_poll_unlock(have);
}
out:
- net_rps_action_and_irq_disable();
+ net_rps_action_and_irq_enable(sd);
#ifdef CONFIG_NET_DMA
/*
^ permalink raw reply related
* Re: [net-next,1/2] add iovnl netlink support
From: Scott Feldman @ 2010-04-21 20:25 UTC (permalink / raw)
To: Arnd Bergmann, Chris Wright; +Cc: davem, netdev
In-Reply-To: <201004212139.22421.arnd@arndb.de>
On 4/21/10 12:39 PM, "Arnd Bergmann" <arnd@arndb.de> wrote:
>>> 1. Setting up the slave device
>>> a) create an SR-IOV VF to assign to a guest
>>> b) create a macvtap device to pass to qemu or vhost
>>> c) attach a tap device to a bridge
>>> d) create a macvlan device and put it into a container
>>> e) create a virtual interface for a VMDq adapter
>>
>> OK, but iovnl isn't doing this.
>
> The set_mac_vlan that Scott's patch adds seems to implement 1a), as far
> as I can tell. Interestingly, this is not actually implemented in
> the enic driver in patch 2/2. So if we all agree that this is out of the
> scope of iovnl, let's just remove it from the interface and find another
> way for it (ethtool, iplink, ..., as listed above).
You're right, not needed for enic since mac addr is included with
port-profile push and vlan membership is implied by port-profile. So I put
set_mac_vlan in there basically to elicit feedback.
There really wouldn't be much different between iplink and iovnl since
they're both rtnetlink...seems we should keep IOV-related APIs in one place.
Maybe there are other IOV APIs to add to iovnl in the future like:
vf <- add_vf(pf)
del_vf(pf, vf)
Ethtool doesn't seem the right place for this.
-scott
^ permalink raw reply
* IPv6 duplicate address detection erroneously marking address as duplicate when a host receives its own multicast packets?
From: Sam Cannell @ 2010-04-21 20:13 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 3576 bytes --]
[c&p from my email to lkml; I was asked to forward it here too. This
occurs on the stock kernels in Debian Lenny and Ubuntu Karmic, as well
as a 2.6.33 I built myself]
Hi,
I've been having some trouble with ip6 duplicate address detection in a
Linux VM (under XVM on OpenSolaris). It seems that the ethernet bridge
in XVM sends a host's own multicast packets back to it, which the
duplicate address detection code in linux decide that another host on
the network is using the same address.
For instance, running:
router4:~ # ip addr add fe80::216:36ff:fe4e:461c/64 dev eth0
I get the following output in tcpdump:
router4:~ # tcpdump -nevpi eth0 ip6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96
bytes
12:33:03.755897 00:16:36:4e:46:1c > 33:33:00:00:00:16, ethertype IPv6
(0x86dd), length 90: (hlim 1, next-header Options (0) payload length:
36) :: > ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum ok] ICMP6,
multicast listener report v2, length 28, 1 group record(s) [gaddr
ff02::1:ff4e:461c to_ex, 0 source(s)]
12:33:04.551772 00:16:36:4e:46:1c > 33:33:ff:4e:46:1c, ethertype IPv6
(0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length:
24) :: > ff02::1:ff4e:461c: [icmp6 sum ok] ICMP6, neighbor solicitation,
length 24, who has fe80::216:36ff:fe4e:461c
12:33:04.551998 00:16:36:4e:46:1c > 33:33:ff:4e:46:1c, ethertype IPv6
(0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length:
24) :: > ff02::1:ff4e:461c: [icmp6 sum ok] ICMP6, neighbor solicitation,
length 24, who has fe80::216:36ff:fe4e:461c
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
And dmesg says:
router4:~ # dmesg
[ 371.024287] eth0: IPv6 duplicate address fe80::216:36ff:fe4e:461c
detected!
And the address sits in 'tentative' mode:
router4:~ # ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
link/ether 00:16:36:4e:46:1c brd ff:ff:ff:ff:ff:ff
inet 192.168.2.128/24 brd 192.168.2.255 scope global eth0
inet6 fe80::216:36ff:fe4e:461c/64 scope link tentative flags 08
valid_lft forever preferred_lft forever
This happens for link-local and global scope address, both when they try
to auto-configure and when set by hand:
[ 463.500328] eth0: IPv6 duplicate address
2404:130:0:1000:216:36ff:fe4e:461c detected!
[ 732.428312] eth0: IPv6 duplicate address
2404:130:0:1000:216:36ff:fe4e:461c detected!
[ 883.812328] eth0: IPv6 duplicate address 2404:130::3:2:1 detected!
I'd happily put this down to a failing in XVM, however the stateless
autoconfiguration RFC (4862) states that the stack shouldn't decide an
address is duplicate based on receipt of a neighbor solicitation message
that it sent itself:
5.4.3. Receiving Neighbor Solicitation Messages
[...]
If the source address of the Neighbor Solicitation is the unspecified
address, the solicitation is from a node performing Duplicate Address
Detection. If the solicitation is from another node, the tentative
address is a duplicate and should not be used (by either node). If
the solicitation is from the node itself (because the node loops back
multicast packets), the solicitation does not indicate the presence
of a duplicate address.
Assuming my understanding of the RFC is correct, this suggests to me
that duplicate address detection in Linux is being a little too hasty to
mark the address as invalid. Thoughts?
Thanks,
Sam Cannell
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply
* Re: PROBLEM: Linux kernel 2.6.31 IPv4 TCP fails to open huge amount of outgoing connections (unable to bind ... )
From: Evgeniy Polyakov @ 2010-04-21 20:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ben Greear, David Miller, Gaspar Chilingarov, netdev
In-Reply-To: <1271877975.7895.3171.camel@edumazet-laptop>
On Wed, Apr 21, 2010 at 09:26:15PM +0200, Eric Dumazet (eric.dumazet@gmail.com) wrote:
> Le mercredi 21 avril 2010 à 22:58 +0400, Evgeniy Polyakov a écrit :
>
> > Damn it, I tried multiple times :)
> > You are right of course!
> >
>
> Here is a formal patch then :)
Ack. Thank you Eric!
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [net-next,1/2] add iovnl netlink support
From: Arnd Bergmann @ 2010-04-21 19:39 UTC (permalink / raw)
To: Chris Wright; +Cc: Scott Feldman, davem, netdev
In-Reply-To: <20100421181021.GC25928@x200.localdomain>
On Wednesday 21 April 2010, Chris Wright wrote:
> * Arnd Bergmann (arnd@arndb.de) wrote:
> > On Wednesday 21 April 2010, Chris Wright wrote:
> > > * Arnd Bergmann (arnd@arndb.de) wrote:
> > > > Since it seems what you really want to do is to do the exchange with the
> > > > switch from here, maybe the hardware configuration part should be moved
> > > > the DCB interface?
> > >
> > > I suppose this would work (although it's a bit odd being out of scope
> > > of DCB spec).
> >
> > It could be anywhere, it doesn't have to be the DCB interface, but could
> > be anything ranging from ethtool to iplink I guess. And we should define
> > it in a way that works for any SR-IOV card, whether it's using Cisco's
> > protocol in firmware, 802.1Qbg VDP in firmware, lldpad to do VDP or
> > none of the above and just provides an internal switch like all the
> > existing NICs.
>
> Heh, that's exactly what iovnl does ;-)
No, according to what you write below, it's exactly what iovnl does *not* do,
i.e. part 1 in my list.
> > 1. Setting up the slave device
> > a) create an SR-IOV VF to assign to a guest
> > b) create a macvtap device to pass to qemu or vhost
> > c) attach a tap device to a bridge
> > d) create a macvlan device and put it into a container
> > e) create a virtual interface for a VMDq adapter
>
> OK, but iovnl isn't doing this.
The set_mac_vlan that Scott's patch adds seems to implement 1a), as far
as I can tell. Interestingly, this is not actually implemented in
the enic driver in patch 2/2. So if we all agree that this is out of the
scope of iovnl, let's just remove it from the interface and find another
way for it (ethtool, iplink, ..., as listed above).
Note that we still need to pass the MAC address and VLAN ID (or a list
of these) to the external switch, my point is just that this should be
separate from enforcing it in the hypervisor.
> > 2) Registering the slave with the switch
> > a) use Cisco protocol in enic firmware (see patch 2/2)
> > b) use standard VDP in lldpad
> > c) use reverse-engineered cisco protocol in some user tool for
> > non-enic adapters.
> > d) use standard VDP in firmware (hopefully this never happens)
> > e) do nothing at all (as we do today)
>
> And this is the step that is the main purpose of iovnl.
>
> Here's the simplest snippet of libvirt to show this. It sends
> set_port_profile netlink messages and then creates macvtap. As simple
> as it gets...
>
> --- a/src/qemu/qemu_conf.c
> +++ b/src/qemu/qemu_conf.c
> @@ -1470,6 +1470,11 @@ qemudPhysIfaceConnect(virConnectPtr conn,
> net->model && STREQ(net->model, "virtio"))
> vnet_hdr = 1;
>
> + setPortProfileId(net->data.direct.linkdev,
> + net->data.direct.mode,
> + net->data.direct.profileid,
> + net->mac);
> +
> rc = openMacvtapTap(net->ifname, net->mac, linkdev, brmode,
> &res_ifname, vnet_hdr);
Ok. In case of VDP, I guess this needs to be extended with the vlan ID
that has been configured, and possibly with a UUID, because we need to
pass the same one on the target machine if we migrate it.
Alternatively, the setPortProfileId could figure out the MAC address and
VLAN ID from the device itself, but then we don't need to pass either of
them.
Arnd
^ permalink raw reply
* Re: Bug#577640: linux-image-2.6.33-2-amd64: Kernel warnings in netns thread
From: Eric W. Biederman @ 2010-04-21 19:36 UTC (permalink / raw)
To: Martín Ferrari
Cc: Ben Hutchings, 577640, netdev, Eric W. Biederman, Alexey Dobriyan,
Mathieu Lacage
In-Reply-To: <o2jb9800b71004210819t6ca61099y17be143527ccbc95@mail.gmail.com>
Martín Ferrari <martin.ferrari@gmail.com> writes:
> I'm not starting a new thread/bug, as this is probably related...
>
> I just discovered that in 2.6.33, if I create a veth inside a
> namespace and then move one of the halves into the main namespace,
> when I kill the namespace, I get one of these warnings followed by an
> oops. This does not happen if the veth is created from the main ns and
> then moved, nor in 2.6.32. This happens both in Qemu and on real
> hardware (both amd64)
>
> To reproduce:
>
> $ sudo ./startns bash
> # ip l a type veth
> # ip l s veth0 netns 1
> # exit
Nasty weird. I did a quick test here, and I'm not seeing that.
Does the 2.6.33 experimental kernel have any patches applied?
The sysfs_add_one path looks like someone we hit a duplicate name,
which is a bug of an entirely different kind. From there it appears
that we later destroy the device not realizing it isn't in sysfs.
Which causes everything to explode.
The sysctl issues appears to be that somewhere we have the ordering of
creates and/or deletes wrong. It is just possible the changes for
batch deletion might be exposing a bug under load.
The sysctl error appears to be in the class of things that should never
happen but that we should handle correctly anyway.
Eric
^ permalink raw reply
* Re: PROBLEM: Linux kernel 2.6.31 IPv4 TCP fails to open huge amount of outgoing connections (unable to bind ... )
From: Eric Dumazet @ 2010-04-21 19:26 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: Ben Greear, David Miller, Gaspar Chilingarov, netdev
In-Reply-To: <20100421185837.GB21249@ioremap.net>
Le mercredi 21 avril 2010 à 22:58 +0400, Evgeniy Polyakov a écrit :
> Damn it, I tried multiple times :)
> You are right of course!
>
Here is a formal patch then :)
[PATCH] tcp: bind() fix when many ports are bound
Port autoselection done by kernel only works when number of bound
sockets is under a threshold (typically 30000).
When this threshold is over, we must check if there is a conflict before
exiting first loop in inet_csk_get_port()
Change inet_csk_bind_conflict() to forbid two reuse-enabled sockets to
bind on same (address,port) tuple (with a non ANY address)
Same change for inet6_csk_bind_conflict()
Reported-by: Gaspar Chilingarov <gasparch@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/inet_connection_sock.c | 16 +++++++++++-----
net/ipv6/inet6_connection_sock.c | 15 ++++++++++-----
2 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index e0a3e35..78cbc39 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -70,13 +70,17 @@ int inet_csk_bind_conflict(const struct sock *sk,
(!sk->sk_bound_dev_if ||
!sk2->sk_bound_dev_if ||
sk->sk_bound_dev_if == sk2->sk_bound_dev_if)) {
+ const __be32 sk2_rcv_saddr = inet_rcv_saddr(sk2);
+
if (!reuse || !sk2->sk_reuse ||
sk2->sk_state == TCP_LISTEN) {
- const __be32 sk2_rcv_saddr = inet_rcv_saddr(sk2);
if (!sk2_rcv_saddr || !sk_rcv_saddr ||
sk2_rcv_saddr == sk_rcv_saddr)
break;
- }
+ } else if (reuse && sk2->sk_reuse &&
+ sk2_rcv_saddr &&
+ sk2_rcv_saddr == sk_rcv_saddr)
+ break;
}
}
return node != NULL;
@@ -120,9 +124,11 @@ again:
smallest_size = tb->num_owners;
smallest_rover = rover;
if (atomic_read(&hashinfo->bsockets) > (high - low) + 1) {
- spin_unlock(&head->lock);
- snum = smallest_rover;
- goto have_snum;
+ if (!inet_csk(sk)->icsk_af_ops->bind_conflict(sk, tb)) {
+ spin_unlock(&head->lock);
+ snum = smallest_rover;
+ goto have_snum;
+ }
}
}
goto next;
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index 0c5e3c3..fb6959c 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -42,11 +42,16 @@ int inet6_csk_bind_conflict(const struct sock *sk,
if (sk != sk2 &&
(!sk->sk_bound_dev_if ||
!sk2->sk_bound_dev_if ||
- sk->sk_bound_dev_if == sk2->sk_bound_dev_if) &&
- (!sk->sk_reuse || !sk2->sk_reuse ||
- sk2->sk_state == TCP_LISTEN) &&
- ipv6_rcv_saddr_equal(sk, sk2))
- break;
+ sk->sk_bound_dev_if == sk2->sk_bound_dev_if)) {
+ if ((!sk->sk_reuse || !sk2->sk_reuse ||
+ sk2->sk_state == TCP_LISTEN) &&
+ ipv6_rcv_saddr_equal(sk, sk2))
+ break;
+ else if (sk->sk_reuse && sk2->sk_reuse &&
+ !ipv6_addr_any(inet6_rcv_saddr(sk2)) &&
+ ipv6_rcv_saddr_equal(sk, sk2))
+ break;
+ }
}
return node != NULL;
^ permalink raw reply related
* Re: cxgb4: Use ntohs() on __be16 value instead of htons()
From: Dimitris Michailidis @ 2010-04-21 19:17 UTC (permalink / raw)
To: Roland Dreier; +Cc: David S. Miller, netdev
In-Reply-To: <ada1ve8r832.fsf@roland-alpha.cisco.com>
On 04/21/2010 11:09 AM, Roland Dreier wrote:
> Use the correct direction of byte-swapping function to fix a mistake
> shown by sparse endianness checking -- c.fl0id is __be16.
>
> Signed-off-by: Roland Dreier<rolandd@cisco.com>
Yes, thanks.
Acked-by: Dimitris Michailidis <dm@chelsio.com>
> ---
> drivers/net/cxgb4/sge.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/cxgb4/sge.c b/drivers/net/cxgb4/sge.c
> index 14adc58..70bf2b2 100644
> --- a/drivers/net/cxgb4/sge.c
> +++ b/drivers/net/cxgb4/sge.c
> @@ -2047,7 +2047,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq,
> adap->sge.ingr_map[iq->cntxt_id] = iq;
>
> if (fl) {
> - fl->cntxt_id = htons(c.fl0id);
> + fl->cntxt_id = ntohs(c.fl0id);
> fl->avail = fl->pend_cred = 0;
> fl->pidx = fl->cidx = 0;
> fl->alloc_failed = fl->large_alloc_failed = fl->starving = 0;
>
^ permalink raw reply
* Re: [stable] [PATCH] tun: orphan an skb on tx
From: Greg KH @ 2010-04-21 19:16 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: stable, Paul Moore, David Woodhouse, netdev, linux-kernel,
qemu-devel, Herbert Xu, Jan Kiszka, David S. Miller
In-Reply-To: <20100421113557.GA31606@redhat.com>
On Wed, Apr 21, 2010 at 02:35:57PM +0300, Michael S. Tsirkin wrote:
> On Tue, Apr 13, 2010 at 05:59:44PM +0300, Michael S. Tsirkin wrote:
> > The following situation was observed in the field:
> > tap1 sends packets, tap2 does not consume them, as a result
> > tap1 can not be closed. This happens because
> > tun/tap devices can hang on to skbs undefinitely.
> >
> > As noted by Herbert, possible solutions include a timeout followed by a
> > copy/change of ownership of the skb, or always copying/changing
> > ownership if we're going into a hostile device.
> >
> > This patch implements the second approach.
> >
> > Note: one issue still remaining is that since skbs
> > keep reference to tun socket and tun socket has a
> > reference to tun device, we won't flush backlog,
> > instead simply waiting for all skbs to get transmitted.
> > At least this is not user-triggerable, and
> > this was not reported in practice, my assumption is
> > other devices besides tap complete an skb
> > within finite time after it has been queued.
> >
> > A possible solution for the second issue
> > would not to have socket reference the device,
> > instead, implement dev->destructor for tun, and
> > wait for all skbs to complete there, but this
> > needs some thought, probably too risky for 2.6.34.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > Tested-by: Yan Vugenfirer <yvugenfi@redhat.com>
> >
> > ---
> >
> > Please review the below, and consider for 2.6.34,
> > and stable trees.
> >
> > drivers/net/tun.c | 4 ++++
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index 96c39bd..4326520 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -387,6 +387,10 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
> > }
> > }
> >
> > + /* Orphan the skb - required as we might hang on to it
> > + * for indefinite time. */
> > + skb_orphan(skb);
> > +
> > /* Enqueue packet */
> > skb_queue_tail(&tun->socket.sk->sk_receive_queue, skb);
> > dev->trans_start = jiffies;
> > --
> > 1.7.0.2.280.gc6f05
>
> This is commit 0110d6f22f392f976e84ab49da1b42f85b64a3c5 in net-2.6
> Please cherry-pick this fix in stable kernels (2.6.32 and 2.6.33).
David Miller queues up the patches for the network subsystem for the
stable trees, and then forwards them to me when he feels they are ready.
So I'll defer to him on this one and wait for it to come from him.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] gianfar: Wait for both RX and TX to stop
From: Kumar Gala @ 2010-04-21 19:13 UTC (permalink / raw)
To: Timur Tabi; +Cc: David Miller, afleming, netdev
In-Reply-To: <z2ged82fe3e1004210733v8fa40902k664549aa9620b13@mail.gmail.com>
On Apr 21, 2010, at 9:33 AM, Timur Tabi wrote:
> On Wed, Apr 21, 2010 at 7:17 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
>> I understand, its more a sense that we are saying we want to time out for what I consider a catastrophic HW failure.
>
> And how else will you detect and recover from such a failure without a
> timeout? And are you absolutely certain that there will never be a
> programming failure that will cause this loop to spin forever?
>
> If you're really opposed to a timeout, you can still use
> spin_event_timeout() by just setting the timeout to -1 and adding a
> comment explaining why.
I'm not opposed, I'm just asking if we are saying we shouldn't be using cpu_relax() for spinning on HW status registers ever.
If we are suggesting that cpu_relax() shouldn't be used in these scenarios going forward I'm ok w/the change you suggest and starting to convert other cpu_relax() calls to use spin_event_timeout()
- k
^ permalink raw reply
* Re: [PATCH net-next-2.6] rps: consistent rxhash
From: Tom Herbert @ 2010-04-21 19:12 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, franco, xiaosuo, netdev
In-Reply-To: <20100420.144106.118596093.davem@davemloft.net>
On Tue, Apr 20, 2010 at 2:41 PM, David Miller <davem@davemloft.net> wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 20 Apr 2010 16:57:01 +0200
>
>> I know many applications using TCP on loopback, they are real :)
>
> This is all true and I support your hashing patch and all of that.
>
> But if we really want TCP over loopback to go fast, there are much
> better ways to do this.
>
> Eric, do you remember that "TCP friends" rough patch I sent you last
> year that essentailly made TCP sockets over loopback behave like
> AF_UNIX ones and just queue the SKBs directly to the destination
> socket without doing any protocol work?
>
This is sounds very interesting! Could you post a patch? :-)
> If we ever got that working, tbench performance would become
> impressive :)
>
^ permalink raw reply
* Re: [PATCH] cxgb3: fix linkup issue
From: Divy Le Ray @ 2010-04-21 19:12 UTC (permalink / raw)
To: Hiroshi Shimamoto; +Cc: netdev, linux-kernel@vger.kernel.org
In-Reply-To: <4BCD0424.8030501@ct.jp.nec.com>
Hiroshi Shimamoto wrote:
> From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
>
> I encountered an issue that not to link up on cxgb3 fabric.
> I bisected and found that this regression was introduced by
> 0f07c4ee8c800923ae7918c231532a9256233eed.
>
> Correct to pass phy_addr to cphy_init() at t3_xaui_direct_phy_prep().
>
> Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
>
Sorry for the review delay, I just came back from some time off.
Acked-by: Divy Le Ray <divy@chelsio.com>
> ---
> drivers/net/cxgb3/ael1002.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/cxgb3/ael1002.c b/drivers/net/cxgb3/ael1002.c
> index 5248f9e..35cd367 100644
> --- a/drivers/net/cxgb3/ael1002.c
> +++ b/drivers/net/cxgb3/ael1002.c
> @@ -934,7 +934,7 @@ static struct cphy_ops xaui_direct_ops = {
> int t3_xaui_direct_phy_prep(struct cphy *phy, struct adapter *adapter,
> int phy_addr, const struct mdio_ops *mdio_ops)
> {
> - cphy_init(phy, adapter, MDIO_PRTAD_NONE, &xaui_direct_ops, mdio_ops,
> + cphy_init(phy, adapter, phy_addr, &xaui_direct_ops, mdio_ops,
> SUPPORTED_10000baseT_Full | SUPPORTED_AUI | SUPPORTED_TP,
> "10GBASE-CX4");
> return 0;
>
^ permalink raw reply
* Re: cxgb4: Make unnecessarily global functions static
From: Roland Dreier @ 2010-04-21 19:03 UTC (permalink / raw)
To: Dimitris Michailidis; +Cc: David S. Miller, netdev
In-Reply-To: <adapr1spr7e.fsf@roland-alpha.cisco.com>
By the way, this results in the following improvement in size in my
x86-64 build, so it's not just source cleanup:
add/remove: 0/4 grow/shrink: 3/6 up/down: 186/-346 (-160)
function old new delta
static.T 18293 18412 +119
t4_ethrx_handler 649 698 +49
handle_trace_pkt 127 145 +18
t4_wr_mbox_meat 728 722 -6
t4_read_rss 147 140 -7
t4_mc_read 201 187 -14
sf1_write 243 228 -15
sf1_read 279 262 -17
t4_edc_read 240 222 -18
t4_pktgl_free 41 - -41
t4_read_indirect 46 - -46
t4_write_indirect 52 - -52
t4_wait_op_done_val 130 - -130
--
Roland Dreier <rolandd@cisco.com> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
^ permalink raw reply
* Re: PROBLEM: Linux kernel 2.6.31 IPv4 TCP fails to open huge amount of outgoing connections (unable to bind ... )
From: Narendra Choyal @ 2010-04-21 19:03 UTC (permalink / raw)
To: Gaspar Chilingarov; +Cc: netdev
In-Reply-To: <g2z46c8cb3e1004201517i5641a75cze2ec5bd33e81fb0f@mail.gmail.com>
use the following command
this will help you out to more connetions
#ip link set eth0 mtu 69
and increase the size of buffer[]
I think this will helps you ( I am student yet now )
^ permalink raw reply
* Re: rps perfomance WAS(Re: rps: question
From: Eric Dumazet @ 2010-04-21 19:01 UTC (permalink / raw)
To: hadi; +Cc: Changli Gao, Rick Jones, David Miller, therbert, netdev, robert,
andi
In-Reply-To: <1271853570.4032.21.camel@bigi>
Le mercredi 21 avril 2010 à 08:39 -0400, jamal a écrit :
> On Tue, 2010-04-20 at 15:13 +0200, Eric Dumazet wrote:
>
>
> > I think your tests are very interesting, maybe could you publish them
> > somehow ? (I forgot to thank you about the previous report and nice
> > graph)
> > perf reports would be good too to help to spot hot points.
>
> Ok ;->
> Let me explain my test setup (which some app types may gasp at;->):
>
> SUT(system under test) was a nehalem single processor (4 cores, 2 SMT
> threads per core).
> SUT runs a udp sink server i wrote (with apologies to Rick Jones[1])
> which forks at most a process per detected cpu and binds to a different
> udp port on each processor.
> Traffic generator sent to SUT upto 750Kpps of udp packets round-robbin
> and varied the destination port to select a different flow on each of
> the outgoing packets. I could further increment the number of flows by
> varying the source address and source port number but in the end i
> settled down to fixed srcip/srcport/destinationip and just varied the
> port number in order to simplify results collection.
> For rps i selected mask "ee" and bound interrupt to cpu0. ee leaves
> out cpu0 and cpu4 from the set of target cpus. Because Nehalem has SMT
> threads, cpu0 and cpu4 are SMT threads that reside on core0 and they
> steal execution cycles from each other - so i didnt want that to happen
> and instead tried to have as many of those cycles as possible for
> demuxing incoming packets.
>
> Overall, in best case scenario rps had 5-7% better throughput than
> nonrps setup. It had upto 10% more cpu use and about 2-5% more latency.
> I am attaching some visualization of the way 8 flows were distributed
> around the different cpus. The diagrams show some samples - but what you
> see there was a good reflection of what i saw in many runs of the tests.
> Essentially, for localization is better with rps which gets better if
> you can somehow map the target cpus as selected by rps to what the app
> binds to.
> Ive also attached a small annotated perf output - sorry i didnt have
> time to dig deeper into the code; maybe later this week. I think my
> biggest problem in this setup was the sky2 driver or hardware poor
> ability to handle lots of traffic.
>
>
> cheers,
> jamal
>
> [1] I want to hump on the SUT with tons of traffic and count packets;
> too complex to do with netperf
Thanks a lot Jamal, this is really useful
Drawback of using a fixed src ip from your generator is that all flows
share the same struct dst entry on SUT. This might explain some glitches
you noticed (ip_route_input + ip_rcv at high level on slave/application
cpus)
Also note your test is one way. If some data was replied we would see
much use of the 'flows'
I notice epoll_ctl() used a lot, are you re-arming epoll each time you
receive a datagram ?
I see slave/application cpus hit _raw_spin_lock_irqsave() and
_raw_spin_unlock_irqrestore().
Maybe a ring buffer could help (instead of a double linked queue) for
backlog, or the double queue trick, if Changli wants to respin his
patch.
^ permalink raw reply
* cxgb4: Make unnecessarily global functions static
From: Roland Dreier @ 2010-04-21 18:59 UTC (permalink / raw)
To: Dimitris Michailidis, David S. Miller; +Cc: netdev
Also put t4_write_indirect() inside "#if 0" to avoid a "defined but not
used" compile warning.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
drivers/net/cxgb4/cxgb4.h | 2 --
drivers/net/cxgb4/sge.c | 2 +-
drivers/net/cxgb4/t4_hw.c | 22 ++++++++++++----------
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/cxgb4/cxgb4.h b/drivers/net/cxgb4/cxgb4.h
index 3d8ff48..4b35dc7 100644
--- a/drivers/net/cxgb4/cxgb4.h
+++ b/drivers/net/cxgb4/cxgb4.h
@@ -651,8 +651,6 @@ int t4_link_start(struct adapter *adap, unsigned int mbox, unsigned int port,
struct link_config *lc);
int t4_restart_aneg(struct adapter *adap, unsigned int mbox, unsigned int port);
int t4_seeprom_wp(struct adapter *adapter, bool enable);
-int t4_read_flash(struct adapter *adapter, unsigned int addr,
- unsigned int nwords, u32 *data, int byte_oriented);
int t4_load_fw(struct adapter *adapter, const u8 *fw_data, unsigned int size);
int t4_check_fw_version(struct adapter *adapter);
int t4_prep_adapter(struct adapter *adapter);
diff --git a/drivers/net/cxgb4/sge.c b/drivers/net/cxgb4/sge.c
index 14adc58..04e5710 100644
--- a/drivers/net/cxgb4/sge.c
+++ b/drivers/net/cxgb4/sge.c
@@ -1471,7 +1471,7 @@ EXPORT_SYMBOL(cxgb4_pktgl_to_skb);
* Releases the pages of a packet gather list. We do not own the last
* page on the list and do not free it.
*/
-void t4_pktgl_free(const struct pkt_gl *gl)
+static void t4_pktgl_free(const struct pkt_gl *gl)
{
int n;
const skb_frag_t *p;
diff --git a/drivers/net/cxgb4/t4_hw.c b/drivers/net/cxgb4/t4_hw.c
index a814a3a..cadead5 100644
--- a/drivers/net/cxgb4/t4_hw.c
+++ b/drivers/net/cxgb4/t4_hw.c
@@ -53,8 +53,8 @@
* at the time it indicated completion is stored there. Returns 0 if the
* operation completes and -EAGAIN otherwise.
*/
-int t4_wait_op_done_val(struct adapter *adapter, int reg, u32 mask,
- int polarity, int attempts, int delay, u32 *valp)
+static int t4_wait_op_done_val(struct adapter *adapter, int reg, u32 mask,
+ int polarity, int attempts, int delay, u32 *valp)
{
while (1) {
u32 val = t4_read_reg(adapter, reg);
@@ -109,9 +109,9 @@ void t4_set_reg_field(struct adapter *adapter, unsigned int addr, u32 mask,
* Reads registers that are accessed indirectly through an address/data
* register pair.
*/
-void t4_read_indirect(struct adapter *adap, unsigned int addr_reg,
- unsigned int data_reg, u32 *vals, unsigned int nregs,
- unsigned int start_idx)
+static void t4_read_indirect(struct adapter *adap, unsigned int addr_reg,
+ unsigned int data_reg, u32 *vals,
+ unsigned int nregs, unsigned int start_idx)
{
while (nregs--) {
t4_write_reg(adap, addr_reg, start_idx);
@@ -120,6 +120,7 @@ void t4_read_indirect(struct adapter *adap, unsigned int addr_reg,
}
}
+#if 0
/**
* t4_write_indirect - write indirectly addressed registers
* @adap: the adapter
@@ -132,15 +133,16 @@ void t4_read_indirect(struct adapter *adap, unsigned int addr_reg,
* Writes a sequential block of registers that are accessed indirectly
* through an address/data register pair.
*/
-void t4_write_indirect(struct adapter *adap, unsigned int addr_reg,
- unsigned int data_reg, const u32 *vals,
- unsigned int nregs, unsigned int start_idx)
+static void t4_write_indirect(struct adapter *adap, unsigned int addr_reg,
+ unsigned int data_reg, const u32 *vals,
+ unsigned int nregs, unsigned int start_idx)
{
while (nregs--) {
t4_write_reg(adap, addr_reg, start_idx++);
t4_write_reg(adap, data_reg, *vals++);
}
}
+#endif
/*
* Get the reply to a mailbox command and store it in @rpl in big-endian order.
@@ -537,8 +539,8 @@ static int flash_wait_op(struct adapter *adapter, int attempts, int delay)
* (i.e., big-endian), otherwise as 32-bit words in the platform's
* natural endianess.
*/
-int t4_read_flash(struct adapter *adapter, unsigned int addr,
- unsigned int nwords, u32 *data, int byte_oriented)
+static int t4_read_flash(struct adapter *adapter, unsigned int addr,
+ unsigned int nwords, u32 *data, int byte_oriented)
{
int ret;
--
Roland Dreier <rolandd@cisco.com> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
^ permalink raw reply related
* Re: PROBLEM: Linux kernel 2.6.31 IPv4 TCP fails to open huge amount of outgoing connections (unable to bind ... )
From: Evgeniy Polyakov @ 2010-04-21 18:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ben Greear, David Miller, Gaspar Chilingarov, netdev
In-Reply-To: <1271875416.7895.3033.camel@edumazet-laptop>
On Wed, Apr 21, 2010 at 08:43:36PM +0200, Eric Dumazet (eric.dumazet@gmail.com) wrote:
> Le mercredi 21 avril 2010 à 22:27 +0400, Evgeniy Polyakov a écrit :
> > On Wed, Apr 21, 2010 at 01:27:33PM +0200, Eric Dumazet (eric.dumazet@gmail.com) wrote:
> > > Here is the patch I use now and my test application is now able to open
> > > and connect 1000000 sockets (ulimit -n 1000000)
> > >
> > > Trick is bind_conflict() must refuse a socket to bind to a port on a non
> > > null IP if another socket already uses same port on same IP.
> > >
> > > Plus the previous patch sent (check a conflict before exiting the search
> > > loop)
> > >
> > > What do you think ?
> >
> > Looks good, but do we want to check only reused socket's address there?
> > What if one of the sockets does not have reuse option turned on, will it
> > break?
> >
>
> Well, if one socket doesnt have reuse option turned on, the previous
> test already works ?
>
> if (!reuse || !sk2->sk_reuse || sk2->sk_state == TCP_LISTEN) {
> if (!sk2_rcv_saddr || !sk_rcv_saddr ||
> sk2_rcv_saddr == sk_rcv_saddr)
> break;
> } else if (reuse && sk2->sk_reuse &&
> sk2_rcv_saddr &&
> sk2_rcv_saddr == sk_rcv_saddr)
> break;
>
> I failed to factorize this complex test :(
Damn it, I tried multiple times :)
You are right of course!
--
Evgeniy Polyakov
^ permalink raw reply
* Re: PROBLEM: Linux kernel 2.6.31 IPv4 TCP fails to open huge amount of outgoing connections (unable to bind ... )
From: Eric Dumazet @ 2010-04-21 18:43 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: Ben Greear, David Miller, Gaspar Chilingarov, netdev
In-Reply-To: <20100421182723.GA17202@ioremap.net>
Le mercredi 21 avril 2010 à 22:27 +0400, Evgeniy Polyakov a écrit :
> On Wed, Apr 21, 2010 at 01:27:33PM +0200, Eric Dumazet (eric.dumazet@gmail.com) wrote:
> > Here is the patch I use now and my test application is now able to open
> > and connect 1000000 sockets (ulimit -n 1000000)
> >
> > Trick is bind_conflict() must refuse a socket to bind to a port on a non
> > null IP if another socket already uses same port on same IP.
> >
> > Plus the previous patch sent (check a conflict before exiting the search
> > loop)
> >
> > What do you think ?
>
> Looks good, but do we want to check only reused socket's address there?
> What if one of the sockets does not have reuse option turned on, will it
> break?
>
Well, if one socket doesnt have reuse option turned on, the previous
test already works ?
if (!reuse || !sk2->sk_reuse || sk2->sk_state == TCP_LISTEN) {
if (!sk2_rcv_saddr || !sk_rcv_saddr ||
sk2_rcv_saddr == sk_rcv_saddr)
break;
} else if (reuse && sk2->sk_reuse &&
sk2_rcv_saddr &&
sk2_rcv_saddr == sk_rcv_saddr)
break;
I failed to factorize this complex test :(
^ permalink raw reply
* Re: PROBLEM: Linux kernel 2.6.31 IPv4 TCP fails to open huge amount of outgoing connections (unable to bind ... )
From: Evgeniy Polyakov @ 2010-04-21 18:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ben Greear, David Miller, Gaspar Chilingarov, netdev
In-Reply-To: <1271849253.7895.1929.camel@edumazet-laptop>
On Wed, Apr 21, 2010 at 01:27:33PM +0200, Eric Dumazet (eric.dumazet@gmail.com) wrote:
> Here is the patch I use now and my test application is now able to open
> and connect 1000000 sockets (ulimit -n 1000000)
>
> Trick is bind_conflict() must refuse a socket to bind to a port on a non
> null IP if another socket already uses same port on same IP.
>
> Plus the previous patch sent (check a conflict before exiting the search
> loop)
>
> What do you think ?
Looks good, but do we want to check only reused socket's address there?
What if one of the sockets does not have reuse option turned on, will it
break?
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [net-next,1/2] add iovnl netlink support
From: Chris Wright @ 2010-04-21 18:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Chris Wright, Scott Feldman, davem, netdev
In-Reply-To: <201004211952.29145.arnd@arndb.de>
* Arnd Bergmann (arnd@arndb.de) wrote:
> On Wednesday 21 April 2010, Chris Wright wrote:
> > * Arnd Bergmann (arnd@arndb.de) wrote:
> > > Since it seems what you really want to do is to do the exchange with the
> > > switch from here, maybe the hardware configuration part should be moved
> > > the DCB interface?
> >
> > I suppose this would work (although it's a bit odd being out of scope
> > of DCB spec).
>
> It could be anywhere, it doesn't have to be the DCB interface, but could
> be anything ranging from ethtool to iplink I guess. And we should define
> it in a way that works for any SR-IOV card, whether it's using Cisco's
> protocol in firmware, 802.1Qbg VDP in firmware, lldpad to do VDP or
> none of the above and just provides an internal switch like all the
> existing NICs.
Heh, that's exactly what iovnl does ;-)
> > I don't expect mgmt app to care about the implementation
> > specifics of an adapter, so it will always send this and iovnl message
> > too. All as part of same setup.
>
> Why? I really see these things as separate. Obviously a management
> tool like libvirt would need to do both these things eventually, but
> each of them has multiple options that can be combined in various
> ways:
>
> 1. Setting up the slave device
> a) create an SR-IOV VF to assign to a guest
> b) create a macvtap device to pass to qemu or vhost
> c) attach a tap device to a bridge
> d) create a macvlan device and put it into a container
> e) create a virtual interface for a VMDq adapter
OK, but iovnl isn't doing this.
> 2) Registering the slave with the switch
> a) use Cisco protocol in enic firmware (see patch 2/2)
> b) use standard VDP in lldpad
> c) use reverse-engineered cisco protocol in some user tool for
> non-enic adapters.
> d) use standard VDP in firmware (hopefully this never happens)
> e) do nothing at all (as we do today)
And this is the step that is the main purpose of iovnl.
Here's the simplest snippet of libvirt to show this. It sends
set_port_profile netlink messages and then creates macvtap. As simple
as it gets...
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -1470,6 +1470,11 @@ qemudPhysIfaceConnect(virConnectPtr conn,
net->model && STREQ(net->model, "virtio"))
vnet_hdr = 1;
+ setPortProfileId(net->data.direct.linkdev,
+ net->data.direct.mode,
+ net->data.direct.profileid,
+ net->mac);
+
rc = openMacvtapTap(net->ifname, net->mac, linkdev, brmode,
&res_ifname, vnet_hdr);
^ 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