* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Sridhar Samudrala @ 2009-08-18 0:12 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Nivedita Singhvi, netdev, Eric Dumazet
In-Reply-To: <alpine.DEB.1.10.0908171848370.15956@gentwo.org>
On Mon, 2009-08-17 at 18:52 -0400, Christoph Lameter wrote:
> On Mon, 17 Aug 2009, Sridhar Samudrala wrote:
>
> > On Mon, 2009-08-17 at 18:13 -0400, Christoph Lameter wrote:
> > > On Mon, 17 Aug 2009, Sridhar Samudrala wrote:
> > >
> > > > What about ethtool -S ? Does it report any errors?
> > >
> > > Neither. This is is a broadcom bnx2 NIC.
> >
> > Are you sure the packets are dropped at the sender?
>
> Yes I am sending 400k messages from the app and the receiver only gets
> 341k @300 byte (which is the line rate). There is no way that the 400k get
> over the line. Also if I reduce SO_SNDBUF then both receiver and
> sender get down to 341k.
>
> I added the output of ethtool -S at the end.
>
> The mcast tool can be had from http://gentwo.org/ll or from my directory
> on www.kernel.org.
>
> > Another place where packet drops/errors are counted is
> > /proc/net/softnet_stat
> > It tracks some counters that could result in drops. I thought these are
> > all receive statistics. But looks like cpu_collision is a tx stat. The
> > name of the structure is netif_rx_stat and it includes cpu_collison
> > counter.
>
> How do I decode that information?
total dropped time_squeeze 0 0 0 0 0 cpu_collision
The first 3 are rx stats and the last one is a tx stat.
Anyway, only the first field(total packets received) seems to be non-zero
in your softnet_stat output on both sender and receiver.
So it is possible that there is some other place in the stack where the packets
are gettting dropped but not counted.
-Sridhar
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Christoph Lameter @ 2009-08-18 0:25 UTC (permalink / raw)
To: Sridhar Samudrala; +Cc: Nivedita Singhvi, netdev, Eric Dumazet
In-Reply-To: <1250554332.25939.46.camel@w-sridhar.beaverton.ibm.com>
On Mon, 17 Aug 2009, Sridhar Samudrala wrote:
> The first 3 are rx stats and the last one is a tx stat.
> Anyway, only the first field(total packets received) seems to be non-zero
> in your softnet_stat output on both sender and receiver.
> So it is possible that there is some other place in the stack where the packets
> are gettting dropped but not counted.
Is the driver responsible? I noticed no rx_drop++ in there.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/3] be2net: Set mac addr in hw regardless of netif_running()
From: David Miller @ 2009-08-18 0:49 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20090817105803.GA10217@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Mon, 17 Aug 2009 16:28:04 +0530
> be_mac_addr_set() currently is broken when netif_running() is false.
>
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next] phonet: fix build when PROC_FS is disabled
From: David Miller @ 2009-08-18 0:49 UTC (permalink / raw)
To: remi; +Cc: randy.dunlap, linux-kernel, linux-next, netdev, akpm
In-Reply-To: <200908172343.44744.remi@remlab.net>
From: "Rémi Denis-Courmont" <remi@remlab.net>
Date: Mon, 17 Aug 2009 23:43:43 +0300
> Le lundi 17 août 2009 23:35:49 Randy Dunlap, vous avez écrit :
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> Fix phonet build when PROC_FS is not enabled:
>>
>> net/built-in.o: In function `pn_sock_open':
>> socket.c:(.text+0x23c649): undefined reference to `seq_open_net'
>> net/built-in.o:(.rodata+0x21018): undefined reference to `seq_release_net'
>>
>> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
>
> Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/3] be2net: refactor be_msix_(un)register() code.
From: David Miller @ 2009-08-18 0:49 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20090817105826.GA10235@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Mon, 17 Aug 2009 16:28:26 +0530
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/3] be2net: destroy mcc queue before tx queues
From: David Miller @ 2009-08-18 0:49 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20090817105841.GA10251@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Mon, 17 Aug 2009 16:28:41 +0530
> As mcc queue uses the tx event queue.
>
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Applied.
^ permalink raw reply
* Re: [RFC net-next PATCH 0/4] qlge: Performance changes for qlge.
From: David Miller @ 2009-08-18 0:57 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev
In-Reply-To: <1250543329-15123-1-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Mon, 17 Aug 2009 14:08:45 -0700
> 1) Do TX completions in send path (with cleaner timer).
You should really do them in NAPI context.
When you do them from hardware interrupt context, they all
get rescheduled into a softirq for the real SKB freeing
work anyways.
So by doing it in NAPI poll, you're avoiding some needless
overhead.
BTW, it's insanely confusing that there is a function called
qlge_msix_tx_isr() that of all things does RX work :-/
> 2) Change RSS queue count to match MSIx vector count instead
> of CPU count. Some platforms didn't offer enough vectors
> for our previous approach.
Ideally you want "max(num_msix_vectors, num_cpus)" because
if you hook up more MSIX vectors than you have cpus it's just
extra overhead and depending upon the descrepency between the
two counts it might unevenly distribute traffic work amongst
the cpus.
> 3) Change large RX buffer logic to use either multiple pages
> or chunks of pages based on MTU and system page size.
>
> Examples:
>
> 64k Pages with 1500 MTU. The RX buffers size would be
> 2048 bytes and there would be 32 per page.
>
> 4k pages with 9000 MTU. The RX buffer size would be 16k,
> or 4 pages per buffer.
This is wasteful, does the card have a mechnism by which it
can dynamically carve up pages depending upon the actual
frame size?
If anything, make sure that skb->truesize gets set to something
reasonable, or else TCP is going to reallocate SKBs when the
receive queue limits are hit.
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: David Miller @ 2009-08-18 1:03 UTC (permalink / raw)
To: tim.bird
Cc: r.schwebel, vda.linux, linux-kernel, linux-embedded, arjan,
kernel, netdev
In-Reply-To: <4A89DB15.6060101@am.sony.com>
From: Tim Bird <tim.bird@am.sony.com>
Date: Mon, 17 Aug 2009 15:35:01 -0700
> Tim Bird wrote:
>> See the definitions of CONF_PRE_OPEN and CON_POST_OPEN
>> in net/ipv4/ipconfig.c
>>
>> They are set to ridiculously long values. In my experience,
>> you can cut them down considerably with no dangerous side
>> effects (but I haven't asked the network guys about the
>> possible downsides).
>
> It turns out that others have seen this delay. Simon
> Arlott recently posted a patch to make the delay avoidable
> at boot time from the kernel command line.
>
> See http://patchwork.kernel.org/patch/31678/
"Rediculiously long" is a relative term.
I have card/switch combinations that take up to 10 seconds to
negotiate a proper link.
So what's there now is actually a quite agressive setting.
And BTW, discussions about stuff like this belong on
netdev@vger.kernel.org, which has been added to the CC:
^ permalink raw reply
* Re: NETROM: Fix use of static buffer
From: David Miller @ 2009-08-18 1:05 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20090817161636.GA26151@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 17 Aug 2009 17:16:36 +0100
> The static variable used by nr_call_to_digi might result in corruption if
> multiple threads are trying to usee a node or neighbour via ioctl. Fixed
> by having the caller pass a structure in. This is safe because nr_add_node
> rsp. nr_add_neigh will allocate a permanent structure, if needed.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied, thanks Ralf.
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Anthony Liguori @ 2009-08-18 1:08 UTC (permalink / raw)
To: Gregory Haskins
Cc: Ingo Molnar, Gregory Haskins, kvm, Avi Kivity, alacrityvm-devel,
linux-kernel, netdev, Michael S. Tsirkin
In-Reply-To: <4A8965E0.8050608@gmail.com>
Gregory Haskins wrote:
> Note: No one has ever proposed to change the virtio-ABI.
virtio-pci is part of the virtio ABI. You are proposing changing that.
You cannot add new kernel modules to guests and expect them to remain
supported. So there is value in reusing existing ABIs
>> I think the reason vbus gets better performance for networking today is
>> that vbus' backends are in the kernel while virtio's backends are
>> currently in userspace.
>>
>
> Well, with all due respect, you also said initially when I announced
> vbus that in-kernel doesn't matter, and tried to make virtio-net run as
> fast as venet from userspace ;) Given that we never saw those userspace
> patches from you that in fact equaled my performance, I assume you were
> wrong about that statement. Perhaps you were wrong about other things too?
>
I'm wrong about a lot of things :-) I haven't yet been convinced that
I'm wrong here though.
One of the gray areas here is what constitutes an in-kernel backend.
tun/tap is a sort of an in-kernel backend. Userspace is still involved
in all of the paths. vhost seems to be an intermediate step between
tun/tap and vbus. The fast paths avoid userspace completely. Many of
the slow paths involve userspace still (like migration apparently).
With vbus, userspace is avoided entirely. In some ways, you could argue
that slirp and vbus are opposite ends of the virtual I/O spectrum.
I believe strongly that we should avoid putting things in the kernel
unless they absolutely have to be. I'm definitely interested in playing
with vhost to see if there are ways to put even less in the kernel. In
particular, I think it would be a big win to avoid knowledge of slots in
the kernel by doing ring translation in userspace. This implies a
userspace transition in the fast path. This may or may not be
acceptable. I think this is going to be a very interesting experiment
and will ultimately determine whether my intuition about the cost of
dropping to userspace is right or wrong.
> Conversely, I am not afraid of requiring a new driver to optimize the
> general PV interface. In the long term, this will reduce the amount of
> reimplementing the same code over and over, reduce system overhead, and
> it adds new features not previously available (for instance, coalescing
> and prioritizing interrupts).
>
I think you have a lot of ideas and I don't know that we've been able to
really understand your vision. Do you have any plans on writing a paper
about vbus that goes into some of your thoughts in detail?
>> If that's the case, then I don't see any
>> reason to adopt vbus unless Greg things there are other compelling
>> features over virtio.
>>
>
> Aside from the fact that this is another confusion of the vbus/virtio
> relationship...yes, of course there are compelling features (IMHO) or I
> wouldn't be expending effort ;) They are at least compelling enough to
> put in AlacrityVM.
This whole AlactricyVM thing is really hitting this nail with a
sledgehammer. While the kernel needs to be very careful about what it
pulls in, as long as you're willing to commit to ABI compatibility, we
can pull code into QEMU to support vbus. Then you can just offer vbus
host and guest drivers instead of forking the kernel.
> If upstream KVM doesn't want them, that's KVMs
> decision and I am fine with that. Simply never apply my qemu patches to
> qemu-kvm.git, and KVM will be blissfully unaware if vbus is present.
As I mentioned before, if you submit patches to upstream QEMU, we'll
apply them (after appropriate review). As I said previously, we want to
avoid user confusion as much as possible. Maybe this means limiting it
to -device or a separate machine type. I'm not sure, but that's
something we can discussion on qemu-devel.
> I
> do hope that I can convince the KVM community otherwise, however. :)
>
Regards,
Anthony Liguori
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: Tim Bird @ 2009-08-18 1:24 UTC (permalink / raw)
To: David Miller
Cc: r.schwebel, vda.linux, linux-kernel, linux-embedded, arjan,
kernel, netdev
In-Reply-To: <20090817.180323.253692704.davem@davemloft.net>
David Miller wrote:
> From: Tim Bird <tim.bird@am.sony.com>
> Date: Mon, 17 Aug 2009 15:35:01 -0700
>
>> Tim Bird wrote:
>>> See the definitions of CONF_PRE_OPEN and CON_POST_OPEN
>>> in net/ipv4/ipconfig.c
>>>
>>> They are set to ridiculously long values. In my experience,
>>> you can cut them down considerably with no dangerous side
>>> effects (but I haven't asked the network guys about the
>>> possible downsides).
>> It turns out that others have seen this delay. Simon
>> Arlott recently posted a patch to make the delay avoidable
>> at boot time from the kernel command line.
>>
>> See http://patchwork.kernel.org/patch/31678/
>
> "Rediculiously long" is a relative term.
No offense intended. I could have phrased this
better. The delays were a few orders of
magnitude longer than apparently needed, on my
embedded test systems with ethernet. I didn't
try eliminating them completely, as in the Arlott patch.
1.5 seconds is a long time for me. My bootup time budget for
the kernel ranges from 0.5 to 3.0 seconds, depending on the
product.
> I have card/switch combinations that take up to 10 seconds to
> negotiate a proper link.
What types of delays are these timeouts supposed to
cover? Networking delays or hardware bring-up delays?
(Or both)? If for networking delays, is this for all
types of networks, or just some (e.g. ones that create
virtual circuits)?
I'm trying to get a sense for whether the card/switch
combinations that would take this long would be encountered
in the types of embedded devices I code for. (TVs, camcorders,
etc.)
>
> So what's there now is actually a quite agressive setting.
>
> And BTW, discussions about stuff like this belong on
> netdev@vger.kernel.org, which has been added to the CC:
I was going to wait to see if this solved Robert's
problem, before widening the discussion. But I'm happy
to find out more about these delays now.
Thanks,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: David Miller @ 2009-08-18 1:27 UTC (permalink / raw)
To: tim.bird
Cc: r.schwebel, vda.linux, linux-kernel, linux-embedded, arjan,
kernel, netdev
In-Reply-To: <4A8A02CA.7040305@am.sony.com>
From: Tim Bird <tim.bird@am.sony.com>
Date: Mon, 17 Aug 2009 18:24:26 -0700
> David Miller wrote:
>> I have card/switch combinations that take up to 10 seconds to
>> negotiate a proper link.
>
> What types of delays are these timeouts supposed to
> cover?
The problem is that if you don't first give at least some time for the
link to come up, the remaining time it takes the link to come up will
end up chewing into the actual bootp/dhcp protocol timeouts. And
that's what we're trying to avoid.
^ permalink raw reply
* Re: mlx4 2.6.31-rc5: SW2HW_EQ failed.
From: Roland Dreier @ 2009-08-18 1:28 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev, Yevgeny Petrilin
In-Reply-To: <alpine.DEB.1.10.0908171814210.15956@gentwo.org>
> > [ 10.256371] mlx4_core 0000:04:00.0: SW2HW_EQ failed (-5)
> Device FW??? The log you wanted follows at the end of this message.
Not sure why there are "???" there... the (-5) error code is an
"internal error" status from the device FW on the event queue
initialization command. Anyway I think the log shows that the problem
is exactly the one fixed in the commit I mentioned -- a423b8a0
("mlx4_core: Allocate and map sufficient ICM memory for EQ context")
from my infiniband.git tree should fix this.
The log
> [ 7425.199430] mlx4_core 0000:04:00.0: irq 70 for MSI/MSI-X
...
> [ 7425.199488] mlx4_core 0000:04:00.0: irq 102 for MSI/MSI-X
shows 33 event queues being allocated (num_possible_cpus() + 1) and that
will hit the issue fixed in that commit.
Assuming this fixes it for you, I guess I should get this into 2.6.31,
since it obviously is hitting not-particularly-exotic systems in
practice. I do wonder why num_possible_cpus() is 32 on your box (since
16 threads is really the max with nehalem EP).
Anyway, here's the patch I mean:
commit a423b8a022d523abe834cefe67bfaf42424150a7
Author: Eli Cohen <eli@mellanox.co.il>
Date: Fri Aug 7 11:13:13 2009 -0700
mlx4_core: Allocate and map sufficient ICM memory for EQ context
The current implementation allocates a single host page for EQ context
memory, which was OK when we only allocated a few EQs. However, since
we now allocate an EQ for each CPU core, this patch removes the
hard-coded limit and makes the allocation depend on EQ entry size and
the number of required EQs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
diff --git a/drivers/net/mlx4/eq.c b/drivers/net/mlx4/eq.c
index c11a052..dae6387 100644
--- a/drivers/net/mlx4/eq.c
+++ b/drivers/net/mlx4/eq.c
@@ -529,29 +529,36 @@ int mlx4_map_eq_icm(struct mlx4_dev *dev, u64 icm_virt)
{
struct mlx4_priv *priv = mlx4_priv(dev);
int ret;
+ int host_pages, icm_pages;
+ int i;
- /*
- * We assume that mapping one page is enough for the whole EQ
- * context table. This is fine with all current HCAs, because
- * we only use 32 EQs and each EQ uses 64 bytes of context
- * memory, or 1 KB total.
- */
+ host_pages = ALIGN(min_t(int, dev->caps.num_eqs, num_possible_cpus() + 1) *
+ dev->caps.eqc_entry_size, PAGE_SIZE) >> PAGE_SHIFT;
+ priv->eq_table.order = order_base_2(host_pages);
priv->eq_table.icm_virt = icm_virt;
- priv->eq_table.icm_page = alloc_page(GFP_HIGHUSER);
+ priv->eq_table.icm_page = alloc_pages(GFP_HIGHUSER, priv->eq_table.order);
if (!priv->eq_table.icm_page)
return -ENOMEM;
priv->eq_table.icm_dma = pci_map_page(dev->pdev, priv->eq_table.icm_page, 0,
- PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+ PAGE_SIZE << priv->eq_table.order,
+ PCI_DMA_BIDIRECTIONAL);
if (pci_dma_mapping_error(dev->pdev, priv->eq_table.icm_dma)) {
- __free_page(priv->eq_table.icm_page);
+ __free_pages(priv->eq_table.icm_page, priv->eq_table.order);
return -ENOMEM;
}
- ret = mlx4_MAP_ICM_page(dev, priv->eq_table.icm_dma, icm_virt);
- if (ret) {
- pci_unmap_page(dev->pdev, priv->eq_table.icm_dma, PAGE_SIZE,
- PCI_DMA_BIDIRECTIONAL);
- __free_page(priv->eq_table.icm_page);
+ icm_pages = (PAGE_SIZE / MLX4_ICM_PAGE_SIZE) << priv->eq_table.order;
+ for (i = 0; i < icm_pages; ++i) {
+ ret = mlx4_MAP_ICM_page(dev, priv->eq_table.icm_dma,
+ icm_virt + i * MLX4_ICM_PAGE_SIZE);
+ if (ret) {
+ if (i)
+ mlx4_UNMAP_ICM(dev, priv->eq_table.icm_virt, i);
+ pci_unmap_page(dev->pdev, priv->eq_table.icm_dma, PAGE_SIZE,
+ PCI_DMA_BIDIRECTIONAL);
+ __free_pages(priv->eq_table.icm_page, priv->eq_table.order);
+ break;
+ }
}
return ret;
@@ -560,11 +567,12 @@ int mlx4_map_eq_icm(struct mlx4_dev *dev, u64 icm_virt)
void mlx4_unmap_eq_icm(struct mlx4_dev *dev)
{
struct mlx4_priv *priv = mlx4_priv(dev);
+ int icm_pages = (PAGE_SIZE / MLX4_ICM_PAGE_SIZE) << priv->eq_table.order;
- mlx4_UNMAP_ICM(dev, priv->eq_table.icm_virt, 1);
- pci_unmap_page(dev->pdev, priv->eq_table.icm_dma, PAGE_SIZE,
- PCI_DMA_BIDIRECTIONAL);
- __free_page(priv->eq_table.icm_page);
+ mlx4_UNMAP_ICM(dev, priv->eq_table.icm_virt, icm_pages);
+ pci_unmap_page(dev->pdev, priv->eq_table.icm_dma,
+ PAGE_SIZE << priv->eq_table.order, PCI_DMA_BIDIRECTIONAL);
+ __free_pages(priv->eq_table.icm_page, priv->eq_table.order);
}
int mlx4_alloc_eq_table(struct mlx4_dev *dev)
diff --git a/drivers/net/mlx4/main.c b/drivers/net/mlx4/main.c
index 5c1afe0..474d1f3 100644
--- a/drivers/net/mlx4/main.c
+++ b/drivers/net/mlx4/main.c
@@ -207,6 +207,7 @@ static int mlx4_dev_cap(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
dev->caps.max_cqes = dev_cap->max_cq_sz - 1;
dev->caps.reserved_cqs = dev_cap->reserved_cqs;
dev->caps.reserved_eqs = dev_cap->reserved_eqs;
+ dev->caps.eqc_entry_size = dev_cap->eqc_entry_sz;
dev->caps.mtts_per_seg = 1 << log_mtts_per_seg;
dev->caps.reserved_mtts = DIV_ROUND_UP(dev_cap->reserved_mtts,
dev->caps.mtts_per_seg);
diff --git a/drivers/net/mlx4/mlx4.h b/drivers/net/mlx4/mlx4.h
index 5bd79c2..34bcc11 100644
--- a/drivers/net/mlx4/mlx4.h
+++ b/drivers/net/mlx4/mlx4.h
@@ -210,6 +210,7 @@ struct mlx4_eq_table {
dma_addr_t icm_dma;
struct mlx4_icm_table cmpt_table;
int have_irq;
+ int order;
u8 inta_pin;
};
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index ce7cc6c..8923c9b 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -206,6 +206,7 @@ struct mlx4_caps {
int max_cqes;
int reserved_cqs;
int num_eqs;
+ int eqc_entry_size;
int reserved_eqs;
int num_comp_vectors;
int num_mpts;
^ permalink raw reply related
* Re: new ipdelay= option for faster netboot
From: Rick Jones @ 2009-08-18 1:31 UTC (permalink / raw)
To: David Miller
Cc: tim.bird, r.schwebel, vda.linux, linux-kernel, linux-embedded,
arjan, kernel, netdev
In-Reply-To: <20090817.180323.253692704.davem@davemloft.net>
David Miller wrote:
> I have card/switch combinations that take up to 10 seconds to
> negotiate a proper link.
Gotta love it when things adhere to specs...
rick jones
has also experienced nic/whatnot combinations that are far from IEEE specs... :(
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: Tim Bird @ 2009-08-18 1:40 UTC (permalink / raw)
To: David Miller
Cc: r.schwebel, vda.linux, linux-kernel, linux-embedded, arjan,
kernel, netdev
In-Reply-To: <20090817.182754.50348941.davem@davemloft.net>
David Miller wrote:
> From: Tim Bird <tim.bird@am.sony.com>
> Date: Mon, 17 Aug 2009 18:24:26 -0700
>
>> David Miller wrote:
>>> I have card/switch combinations that take up to 10 seconds to
>>> negotiate a proper link.
>> What types of delays are these timeouts supposed to
>> cover?
>
> The problem is that if you don't first give at least some time for the
> link to come up, the remaining time it takes the link to come up will
> end up chewing into the actual bootp/dhcp protocol timeouts. And
> that's what we're trying to avoid.
What link? I'm not that familiar with networking.
Assuming I'm using ethernet, what link needs to come up?
Is this something to do with power propagation to the
physical wire? Is there some MAC layer negotiation
between the card and the switch? Is it the time for
the switch to do speed detection?
And, can any of this be more accurately determined
or guessed-at with knowledge of the onboard hardware?
Or is it dependent on external conditions?
Where would be a good place to find out more about
startup delays for networking chips and/or protocols?
Our usual solution is to kick the can down the road
and let user-space initialize anything that takes a long
time, while we do other stuff like focus the camera or display
the TV picture. It would be good to learn more about
this.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH 1/4] net: skb_orphan on dev_hard_start_xmit
From: David Miller @ 2009-08-18 1:47 UTC (permalink / raw)
To: herbert
Cc: rusty, patrick.ohly, netdev, virtualization, divy, rolandd, xemul,
dcbw, libertas-dev
In-Reply-To: <20090705033408.GB7430@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 5 Jul 2009 11:34:08 +0800
> Here's an even crazier idea that doesn't use dummy descriptors.
>
> xmit(skb)
>
> if (TX queue contains no interrupting descriptor &&
> qdisc is empty)
> mark TX descriptor as interrupting
>
> if (TX queue now contains an interrupting descriptor &&
> qdisc len < 2)
> stop queue
>
> if (TX ring full)
> stop queue
>
> clean()
>
> do work
> wake queue as per usual
I'm pretty sure that for normal TCP and UDP workloads, this is just
going to set the interrupt bit on the first packet that gets into the
queue, and then not in the rest.
TCP just loops over packets in the send queue, and at initial state
the qdisc will be empty.
It's very hard to get this to work as well as if we had a real
queue empty interrupt status event.
Even if you get upstream status from the protocols saying "there's
more packets coming" via some flag in the SKB, that only says what one
client feeding the TX ring is about to do.
It says nothing about other threads of control which are about to start
feeding packets to the same device.
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: David Miller @ 2009-08-18 1:56 UTC (permalink / raw)
To: tim.bird
Cc: r.schwebel, vda.linux, linux-kernel, linux-embedded, arjan,
kernel, netdev
In-Reply-To: <4A8A06A0.2070402@am.sony.com>
From: Tim Bird <tim.bird@am.sony.com>
Date: Mon, 17 Aug 2009 18:40:48 -0700
> David Miller wrote:
>> From: Tim Bird <tim.bird@am.sony.com>
>> Date: Mon, 17 Aug 2009 18:24:26 -0700
>>
>>> David Miller wrote:
>>>> I have card/switch combinations that take up to 10 seconds to
>>>> negotiate a proper link.
>>> What types of delays are these timeouts supposed to
>>> cover?
>>
>> The problem is that if you don't first give at least some time for the
>> link to come up, the remaining time it takes the link to come up will
>> end up chewing into the actual bootp/dhcp protocol timeouts. And
>> that's what we're trying to avoid.
>
> What link? I'm not that familiar with networking.
The speed and duplex settings which are negotiated or forced between
the ethernet card and whatever is at the other end of the cable.
> Assuming I'm using ethernet, what link needs to come up?
All modern ethernet cards do autonegotiation of link parameters
with whatever is at the other end of the ethernet cable. Cards
created ages ago which only support 10MB half-duplex typically
do not support autonegotiation at all.
This autonegotiation works like a protocol where the two link partners
go back and forth trying to figure out the best speed and duplex
settings to use. There are advertisements of link capabilities and
stuff like that.
It should happen almost instantaneously, but there are millions
upon millions of cruddy parts out there, and some of them take
a long time to go through this negotiation process.
^ permalink raw reply
* Re: [PATCH] Speed-up pfifo_fast lookup using a bitmap
From: David Miller @ 2009-08-18 2:03 UTC (permalink / raw)
To: jarkao2; +Cc: krkumar2, kaber, netdev, herbert
In-Reply-To: <20090814213643.GA3179@ami.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Fri, 14 Aug 2009 23:36:43 +0200
> I definitely can't see a reason to make this variable public, and
> prefer the private (v2) version (which still lacks a changelog, btw).
I'm fine with patch v2, but yes it needs to be properly submitted
with a real changelog before I can apply it :-)
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: david @ 2009-08-18 2:45 UTC (permalink / raw)
To: Rick Jones
Cc: David Miller, tim.bird, r.schwebel, vda.linux, linux-kernel,
linux-embedded, arjan, kernel, netdev
In-Reply-To: <4A8A0454.8000902@hp.com>
On Mon, 17 Aug 2009, Rick Jones wrote:
> David Miller wrote:
>> I have card/switch combinations that take up to 10 seconds to
>> negotiate a proper link.
>
> Gotta love it when things adhere to specs...
the default on Cisco switches is to wait 30 seconds before fully enabling
the port so that it can listen for spanning tree broadcasts.
for windows systems this doesn't cause any problems (they take long enough
to boot), but for a tightly configured linux box it can be fully booted
long before the switch decides to enable the port (for that matter, I have
a bare-metal install process that takes about 90 seconds from hitting
power, from a CD. I could probably speed things up by switching to USB
boot media)
David Lang
^ permalink raw reply
* Re: [PATCH] Revert netlink ABI change to gnet_stats_basic
From: David Miller @ 2009-08-18 4:34 UTC (permalink / raw)
To: mspang; +Cc: eric.dumazet, linux-kernel, netdev
In-Reply-To: <118a63b80908161310r69c0810fg247341f09ced8932@mail.gmail.com>
From: Michael Spang <mspang@csclub.uwaterloo.ca>
Date: Sun, 16 Aug 2009 16:10:12 -0400
> On Sun, Aug 16, 2009 at 3:36 PM, Eric Dumazet<eric.dumazet@gmail.com> wrote:
>> Michael Spang a écrit :
>>
>> OK, then we are stuck to use a separate definition for user land
>> and kernel land, or risk various side effects, like performance hit
>> and security risk.
>>
>> Thanks a lot Michael
>>
>> [PATCH] net: restore gnet_stats_basic to previous definition
>
> Applied it and it works for me, thanks.
Applied to net-2.6, thanks everyone.
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: Willy Tarreau @ 2009-08-18 4:56 UTC (permalink / raw)
To: david
Cc: Rick Jones, David Miller, tim.bird, r.schwebel, vda.linux,
linux-kernel, linux-embedded, arjan, kernel, netdev
In-Reply-To: <alpine.DEB.2.00.0908171942430.30426@asgard.lang.hm>
On Mon, Aug 17, 2009 at 07:45:33PM -0700, david@lang.hm wrote:
> On Mon, 17 Aug 2009, Rick Jones wrote:
>
> >David Miller wrote:
> >>I have card/switch combinations that take up to 10 seconds to
> >>negotiate a proper link.
> >
> >Gotta love it when things adhere to specs...
>
> the default on Cisco switches is to wait 30 seconds before fully enabling
> the port so that it can listen for spanning tree broadcasts.
And this causes a lot of trouble in high availability environments,
because the link is up but unusable. So if you're using it as a primary
bond link you can lose connectivity for that time. Fortunately, you can
configure the port in "switchport mode access", "portfast" mode to avoid
this annoying delay.
Willy
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: Denys Vlasenko @ 2009-08-18 4:56 UTC (permalink / raw)
To: David Miller
Cc: tim.bird, r.schwebel, linux-kernel, linux-embedded, arjan, kernel,
netdev
In-Reply-To: <20090817.182754.50348941.davem@davemloft.net>
On Tuesday 18 August 2009 03:27, David Miller wrote:
> From: Tim Bird <tim.bird@am.sony.com>
> Date: Mon, 17 Aug 2009 18:24:26 -0700
>
> > David Miller wrote:
> >> I have card/switch combinations that take up to 10 seconds to
> >> negotiate a proper link.
> >
> > What types of delays are these timeouts supposed to
> > cover?
>
> The problem is that if you don't first give at least some time for the
> link to come up, the remaining time it takes the link to come up will
> end up chewing into the actual bootp/dhcp protocol timeouts. And
> that's what we're trying to avoid.
But in this case, they assign a static IP. They do not use DHCP.
So they pay this time penalty even if they wouldn't use networking
until sometime later (or never).
Since DHCP and any other networking activity like TCP connects
accomodate packet loss, things should work even without any delay
in kernel IP config code. The delay will be just shifted to the
moment when first DHCP/TCP/whatever negotiation happens.
If dropping delays altogether sounds too big a change,
then it makes sense at least to allow people to tweak it with
ipdelay=TIME_IN_MS
--
vda
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: David Miller @ 2009-08-18 5:00 UTC (permalink / raw)
To: vda.linux
Cc: tim.bird, r.schwebel, linux-kernel, linux-embedded, arjan, kernel,
netdev
In-Reply-To: <200908180656.54011.vda.linux@googlemail.com>
From: Denys Vlasenko <vda.linux@googlemail.com>
Date: Tue, 18 Aug 2009 06:56:53 +0200
> Since DHCP and any other networking activity like TCP connects
> accomodate packet loss, things should work even without any delay
> in kernel IP config code. The delay will be just shifted to the
> moment when first DHCP/TCP/whatever negotiation happens.
Until the link is up, the packet scheduler just holds onto packets
and queued them up.
When the link comes up, this queue is released and the packets
sent out.
That's why it's beneficial to wait some time until the link
comes up before we start sending stuff out. Because otherwise
any timeouts used will be inaccurate.
This could code be spiffed up to wait for the link up indication
on devices it cares about. Feel free to code that up :-)
^ permalink raw reply
* [GIT]: Networking
From: David Miller @ 2009-08-18 5:09 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) netxen fixes from Dhanajay Pdadke and Amit Kumar Salecha
2) e1000e/ixgbe fixes from the Intel folks
3) Wireless bug fixes via John Linville
4) TUN ioctl race fix from Herbert Xu
5) Eric Dumazet discovered that several ->getname implementations
leak uninitialized kernel memory to userspace.
6) mwl8k driver fixes from Lennert Buytenhek
7) Fix 8139cp issues caught by DMA debugging, from Francois Romieu
8) Drivers that support netpoll need to not assume the state of
interrupt enabling when ->hard_start_xmit is called. Fix from
Dongdong Deng
9) IEEE802154 protocol needs to provide dummy get/setsockopt else
we oops, plus an ioctl fix from Dmitry Eremin-Solenikov
10) cnic/bnx2 fixes from Michael Chan
11) can protocol oops fixer from Oliver Hartkopp
12) New device IDs for 3c90x and pegasus drivers.
13) SCTP forgets to destroy per-cpu variable on unload, from Rafael Laufer
DCCP has the same problem, fixed by Wei Yongjun
14) Various read-past-end-of-buffer fixes from Roel Kluin
15) Gianfar loses VLAN state on restart.
16) genetlink datastructure change broke userland, split into kernel
private and userland copy. Regression fixed by Eric Dumazet.
Please pull, thanks a lot!
The following changes since commit df4ecf1524c7793de3121b2d4e5fc6bcc0da3bfb:
Linus Torvalds (1):
Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Amit Kumar Salecha (1):
netxen: remove netxen workqueue
Bob Dunlop (1):
libertas: correct packing of rxpd structure
Bruce Allan (3):
e1000e: fix acquisition of SW/FW/HW semaphore for ICHx parts
e1000e: fix potential NVM corruption on ICH9 with 8K bank size
e1000e: WoL does not work on 82577/82578 with manageability enabled
Chris Snook (1):
MAINTAINERS: update atlx contact info
Christian Lamparter (1):
ar9170usb: fix spurious firmware related message
Dan Carpenter (1):
ar9170: fix read & write outside array bounds
David S. Miller (5):
Merge branch 'for-linus' of git://git.kernel.org/.../lowpan/lowpan
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
Revert "libertas: Read buffer overflow"
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Dhananjay Phadke (2):
netxen: fix dma mask update calculation
netxen: free napi resources during detach
Dmitry Eremin-Solenikov (2):
af_ieee802154: fix ioctl processing
af_ieee802154: provide dummy get/setsockopt
Don Skidmore (1):
ixgbe: fix issues setting rx-usecs with legacy interrupts
Dongdong Deng (1):
drivers/net: fixed drivers that support netpoll use ndo_start_xmit()
Eric Dumazet (8):
phonet: phonet_device_get() fix
rose: Fix rose_getname() leak
econet: Fix econet_getname() leak
netrom: Fix nr_getname() leak
appletalk: fix atalk_getname() leak
irda: Fix irda_getname() leak
can: Fix raw_getname() leak
net: restore gnet_stats_basic to previous definition
Francois Romieu (1):
8139cp: balance dma_map_single vs dma_unmap_single pair
Greg Ungerer (1):
fec: fix FEC driver packet transmission breakage
Herbert Xu (1):
tun: Extend RTNL lock coverage over whole ioctl
Joe Perches (1):
MAINTAINERS: additional NETWORKING [GENERAL] and NETWORKING DRIVERS patterns
Jussi Mäki (1):
Fix xfrm hash collisions by changing __xfrm4_daddr_saddr_hash to hash addresses with addition
Lennert Buytenhek (5):
mwl8k: fix NULL pointer dereference on receive out-of-memory
mwl8k: add various missing GET_HW_SPEC endian conversions
mwl8k: call pci_unmap_single() before accessing command structure again
mwl8k: prevent crash in ->configure_filter() if no interface was added
mwl8k: prevent module unload hang
Lucy Liu (1):
ixgbe: Fix receive on real device when VLANs are configured
Luis R. Rodriguez (1):
mac80211: fix panic when splicing unprepared TIDs
Michael Chan (5):
cnic: Fix symbol_put_addr() panic on ia64.
cnic: Refine registration with bnx2.
bnx2: Use mutex on slow path cnic calls.
cnic: Fix locking in start/stop calls.
cnic: Fix locking in init/exit calls.
Oliver Hartkopp (1):
can: fix oops caused by wrong rtnl newlink usage
Pascal Terjan (1):
Add IDs for 3C905B-TX Fast Etherlink XL PCI
Pavel Roskin (1):
rt2x00: fix memory corruption in rf cache, add a sanity check
Petko Manolov (1):
pegasus: Add new device ID.
Rafael Laufer (1):
sctp: fix missing destroy of percpu counter variable in sctp_proc_exit()
Ralf Baechle (1):
NETROM: Fix use of static buffer
Roel Kluin (2):
irda: fix read buffer overflow
atlx: strncpy does not null terminate string
Tom Goff (1):
gre: Fix MTU calculation for bound GRE tunnels
Wei Yongjun (1):
dccp: missing destroy of percpu counter variable while unload module
Xiaotian Feng (1):
e1000e: fix use of pci_enable_pcie_error_reporting
Yi Zou (3):
ixgbe: Pass rx_ring directly in ixgbe_configure_srrctl()
ixgbe: Disable packet split only on FCoE queues in 82599
ixgbe: Do not return 0 in ixgbe_fcoe_ddp() upon FCP_RSP in DDP completion
Yong Zhang (1):
gianfar: keep vlan related state when restart
Zhu Yi (1):
ipw2x00: Write outside array bounds
roel kluin (4):
pcnet32: Read buffer overflow
zorro8390: Fix read buffer overflow in zorro8390_init_one()
mlx4_en: Fix read buffer overflow in mlx4_en_complete_rx_desc()
via-velocity: Fix test of mii_status bit VELOCITY_DUPLEX_FULL
MAINTAINERS | 7 ++-
drivers/net/3c59x.c | 4 +
drivers/net/8139cp.c | 5 +-
drivers/net/atl1c/atl1c_ethtool.c | 8 +-
drivers/net/atlx/atl1.c | 8 +-
drivers/net/b44.c | 5 +-
drivers/net/bnx2.c | 17 +++--
drivers/net/bnx2.h | 1 +
drivers/net/can/dev.c | 7 ++
drivers/net/cnic.c | 143 ++++++++++++++++++++++---------
drivers/net/cnic.h | 1 +
drivers/net/cnic_if.h | 1 +
drivers/net/e1000e/ich8lan.c | 94 +++++++++-----------
drivers/net/e1000e/netdev.c | 22 +++---
drivers/net/fec.c | 9 +-
drivers/net/gianfar.c | 12 ++-
drivers/net/irda/w83977af_ir.c | 2 +-
drivers/net/ixgbe/ixgbe.h | 2 +
drivers/net/ixgbe/ixgbe_ethtool.c | 27 ++++--
drivers/net/ixgbe/ixgbe_fcoe.c | 2 +-
drivers/net/ixgbe/ixgbe_main.c | 90 +++++++------------
drivers/net/mlx4/en_rx.c | 5 +-
drivers/net/netxen/netxen_nic.h | 2 +-
drivers/net/netxen/netxen_nic_init.c | 7 --
drivers/net/netxen/netxen_nic_main.c | 105 ++++++++++++++--------
drivers/net/pcnet32.c | 2 +-
drivers/net/tulip/tulip_core.c | 5 +-
drivers/net/tun.c | 50 ++++-------
drivers/net/ucc_geth.c | 5 +-
drivers/net/usb/pegasus.h | 2 +
drivers/net/via-rhine.c | 5 +-
drivers/net/via-velocity.c | 2 +-
drivers/net/wireless/ath/ar9170/main.c | 5 +-
drivers/net/wireless/ath/ar9170/usb.c | 6 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 2 +-
drivers/net/wireless/libertas/assoc.c | 18 ++--
drivers/net/wireless/libertas/hostcmd.h | 4 +-
drivers/net/wireless/mwl8k.c | 31 ++++---
drivers/net/wireless/rt2x00/rt2x00.h | 6 +-
drivers/net/zorro8390.c | 3 +
include/linux/gen_stats.h | 5 +
include/net/act_api.h | 2 +-
include/net/gen_stats.h | 10 +-
include/net/netfilter/xt_rateest.h | 2 +-
include/net/sch_generic.h | 2 +-
net/appletalk/ddp.c | 1 +
net/can/raw.c | 1 +
net/core/gen_estimator.c | 12 ++--
net/core/gen_stats.c | 11 ++-
net/dccp/proto.c | 1 +
net/econet/af_econet.c | 1 +
net/ieee802154/af_ieee802154.c | 8 +-
net/ieee802154/dgram.c | 14 +++
net/ieee802154/raw.c | 14 +++
net/ipv4/ip_gre.c | 2 +-
net/irda/af_irda.c | 1 +
net/mac80211/agg-tx.c | 8 ++
net/netfilter/xt_RATEEST.c | 2 +-
net/netrom/af_netrom.c | 1 +
net/netrom/nr_route.c | 21 +++--
net/phonet/pn_dev.c | 2 +-
net/rose/af_rose.c | 1 +
net/sched/sch_atm.c | 2 +-
net/sched/sch_cbq.c | 2 +-
net/sched/sch_drr.c | 2 +-
net/sched/sch_hfsc.c | 2 +-
net/sched/sch_htb.c | 2 +-
net/sctp/protocol.c | 1 +
net/xfrm/xfrm_hash.h | 2 +-
69 files changed, 520 insertions(+), 347 deletions(-)
^ permalink raw reply
* Re: [PATCH] drivers/net: fixed drivers that support netpoll use ndo_start_xmit()
From: DDD @ 2009-08-18 5:59 UTC (permalink / raw)
To: David Miller, mpm; +Cc: netdev, linux-kernel, Bruce.Ashfield, jason.wessel
In-Reply-To: <20090814.163232.234331420.davem@davemloft.net>
On Fri, 2009-08-14 at 16:32 -0700, David Miller wrote:
> From: Matt Mackall <mpm@selenic.com>
> Date: Fri, 14 Aug 2009 10:33:39 -0500
>
> > On Fri, 2009-08-14 at 13:12 +0800, DDD wrote:
> >> The NETPOLL API requires that interrupts remain disabled in
> >> netpoll_send_skb(). The use of spin_lock_irq() and
> spin_unlock_irq()
> >> in the NETPOLL API callbacks causes the interrupts to get enabled
> and
> >> can lead to kernel instability.
> >>
> >> The solution is to use spin_lock_irqsave() and
> spin_unlock_restore()
> >> to prevent the irqs from getting enabled while in
> netpoll_send_skb().
> ...
> >> Signed-off-by: Dongdong Deng <dongdong.deng@windriver.com>
> >> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> >> Acked-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> >
> > Acked-by: Matt Mackall <mpm@selenic.com>
>
> Applied, thanks everyone.
Thanks. :-)
>
> > Perhaps we should also have a WARN_ONCE if start_xmit returns with
> > interrupts enabled?
>
> Probably a good idea.
I think it is a good idea too, thanks for your suggestion, Matt.
I will do a tiny patch for it shortly.
Dongdong
^ 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