* Re: [net-next.git] stmmac: remove useless csum flag
From: David Miller @ 2013-08-22 3:38 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, sonic.zhang
In-Reply-To: <1377069074-4488-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 21 Aug 2013 09:11:14 +0200
> This patch removes the no_csum_insertion private parameter that is not used anymore
> and, also, the "likely" annotation from the condition that is not in a critical path.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Sonic Zhang <sonic.zhang@analog.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC 0/2] Account for duplicate ACKs with invalid SACK-blocks
From: David Miller @ 2013-08-22 3:32 UTC (permalink / raw)
To: christoph.paasch
Cc: eric.dumazet, netdev, kernel, bugfood-ml, benjamin.hesmans
In-Reply-To: <1376940568-16512-1-git-send-email-christoph.paasch@uclouvain.be>
From: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Mon, 19 Aug 2013 21:29:26 +0200
> There exist sequence-number rewriting middleboxes, who do not modify the
> sequence-number in the SACK-blocks.
These are bugs that the vendor's should fix, not something we should
cater to at all.
I'm not applying patches like these, and I've rejected similar
workarounds in the past 18 years, so this position is strong and
consistent.
Sorry.
^ permalink raw reply
* Re: [PATCH net] skge: dma_sync the whole receive buffer
From: poma @ 2013-08-22 3:30 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Hemminger, David Miller, netdev, Linus Torvalds
In-Reply-To: <20130822004023.GA26938@kroah.com>
On 22.08.2013 02:40, Greg KH wrote:
> On Wed, Aug 21, 2013 at 06:04:11PM +0200, poma wrote:
>> Signor Greg you are supposed to be very resourceful guy, especially in
>> matters concerning the hardware, so please if you can set aside your
>> valuable time and help us finally resolve this issue.
>
> Please take it up with Stephen, it's his driver, not mine.
>
> greg k-h
>
I guess I wrongly assumed that developers help each other when they get
stuck. Isn't it obvious that Steph and Dave already decided to ship the
broken module in da birthday kernel. What can I do in the first place,
as a simple user. That's why I asked you to help.
However thank you for the answer.
poma
^ permalink raw reply
* Re: [PATCH RFC net-next] ipv6: avoid high order memory allocations for /proc/net/ipv6_route
From: Hannes Frederic Sowa @ 2013-08-22 3:16 UTC (permalink / raw)
To: netdev, yoshfuji
In-Reply-To: <20130821175024.GA14419@order.stressinduktion.org>
On Wed, Aug 21, 2013 at 07:50:24PM +0200, Hannes Frederic Sowa wrote:
> I created this patch in a hurry while trying to get the rt6i_flags of
> the routing entries on a system with lots of routes (I later cleaned it
> up a bit).
>
> The current approach for dumping routes over netlink is to redump a tree
> as soon as the serialnumber on the nodes changes. Is this behavior more
> preferable as to just ignore the routes for that moment? I am in favour
> of not restarting the dump on /proc/net/ipv6_route.
Ok, I hit the same panics as Patrick once did
while some more stress testing this change
(http://permalink.gmane.org/gmane.linux.network/151391).
As I read this up, this was also the reason the serial checks where
introduced. It also tries to skip visited notes, so please void my
question above.
The reason is a disconnected fib6_node in FWS_U state trying to walk
up. I'll investigate if we can fix this up in the walker post-cleanup on
fib6_repair_tree/fib6_del_route (then we could also remove the serial
number checks on inet6_dump_fib) or I will make the appropriate serial
changes to this patch, too.
> +int ipv6_route_open(struct inode *inode, struct file *file)
> +{
> + return seq_open_net(inode, file, &ipv6_route_seq_ops,
> + sizeof(struct fib6_walker_t));
> +}
> +
sizeof(struct ipv6_route_iter) here, of course. :(
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH linux-next] ipv6: fix missing braces in ip6_tnl_add_linklocal
From: David Miller @ 2013-08-22 3:05 UTC (permalink / raw)
To: vincent.stehle
Cc: netdev, linux-kernel, linux-next, kuznet, jmorris, yoshfuji,
kaber, dingtianhong
In-Reply-To: <1377123597-26515-1-git-send-email-vincent.stehle@laposte.net>
I already reverted the change in question.
^ permalink raw reply
* Re: [PATCH RESEND net-next V2 2/3] net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
From: Greg KH @ 2013-08-22 2:56 UTC (permalink / raw)
To: Enrico Mioso
Cc: oliver-GvhC2dPhHPQdnm+yROfE0A, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1377138641-2765-3-git-send-email-mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Aug 22, 2013 at 04:30:40AM +0200, Enrico Mioso wrote:
> This driver supports devices using the NCM protocol as an encapsulation layer
> for other protocols, like the E3131 Huawei 3G modem. This driver was heavily inspired by the qmi_wwan approach & code model.
Line-wrap your changelog lines?
>
> Suggested-by: Bjorn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Signed-off-by: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/net/usb/Kconfig | 11 +++++++++++
> drivers/net/usb/Makefile | 1 +
> 2 files changed, 12 insertions(+)
I think you forgot to add the driver to the patch :(
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH RESEND net-next V2 3/3] net: cdc_ncm: remove non-standard NCM device IDs
From: Enrico Mioso @ 2013-08-22 2:30 UTC (permalink / raw)
To: gregkh, oliver, linux-usb, netdev, linux-kernel; +Cc: Enrico Mioso
In-Reply-To: <1377138641-2765-1-git-send-email-mrkiko.rs@gmail.com>
Remove device IDs of NCM-like (but not NCM-conformant) devices, that are
handled by the huawwei_cdc_ncm driver now.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
---
drivers/net/usb/cdc_ncm.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 62686be..31f43f7 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1236,17 +1236,6 @@ static const struct usb_device_id cdc_devs[] = {
.driver_info = (unsigned long)&wwan_info,
},
- /* Huawei NCM devices disguised as vendor specific */
- { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x16),
- .driver_info = (unsigned long)&wwan_info,
- },
- { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x46),
- .driver_info = (unsigned long)&wwan_info,
- },
- { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x76),
- .driver_info = (unsigned long)&wwan_info,
- },
-
/* Infineon(now Intel) HSPA Modem platform */
{ USB_DEVICE_AND_INTERFACE_INFO(0x1519, 0x0443,
USB_CLASS_COMM,
--
1.7.10.4
^ permalink raw reply related
* [PATCH RESEND net-next V2 2/3] net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
From: Enrico Mioso @ 2013-08-22 2:30 UTC (permalink / raw)
To: gregkh, oliver, linux-usb, netdev, linux-kernel; +Cc: Enrico Mioso
In-Reply-To: <1377138641-2765-1-git-send-email-mrkiko.rs@gmail.com>
This driver supports devices using the NCM protocol as an encapsulation layer
for other protocols, like the E3131 Huawei 3G modem. This driver was heavily inspired by the qmi_wwan approach & code model.
Suggested-by: Bjorn Mork <bjorn@mork.no>
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
---
drivers/net/usb/Kconfig | 11 +++++++++++
drivers/net/usb/Makefile | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index d84bfd4..6e56751 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -242,6 +242,17 @@ config USB_NET_CDC_NCM
* ST-Ericsson M343 HSPA Mobile Broadband Modem (reference design)
* Ericsson F5521gw Mobile Broadband Module
+config USB_NET_HUAWEI_CDC_NCM
+ tristate "Huawei-style CDC NCM support"
+ depends on USB_USBNET
+ select USB_WDM
+ select USB_NET_CDC_NCM
+ help
+ This driver aims to support huawei-style NCM devices, that use ncm as a
+ transport for other protocols.
+ To compile this driver as a module, choose M here: the module will be
+ called huawei_cdc_ncm.
+
config USB_NET_CDC_MBIM
tristate "CDC MBIM support"
depends on USB_USBNET
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index e817178..fd0e6a7 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_USB_IPHETH) += ipheth.o
obj-$(CONFIG_USB_SIERRA_NET) += sierra_net.o
obj-$(CONFIG_USB_NET_CX82310_ETH) += cx82310_eth.o
obj-$(CONFIG_USB_NET_CDC_NCM) += cdc_ncm.o
+obj-$(CONFIG_USB_NET_HUAWEI_CDC_NCM) += huawei_cdc_ncm.o
obj-$(CONFIG_USB_VL600) += lg-vl600.o
obj-$(CONFIG_USB_NET_QMI_WWAN) += qmi_wwan.o
obj-$(CONFIG_USB_NET_CDC_MBIM) += cdc_mbim.o
--
1.7.10.4
^ permalink raw reply related
* [PATCH RESEND net-next V2 1/3] net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
From: Enrico Mioso @ 2013-08-22 2:30 UTC (permalink / raw)
To: gregkh, oliver, linux-usb, netdev, linux-kernel; +Cc: Enrico Mioso
In-Reply-To: <1377138641-2765-1-git-send-email-mrkiko.rs@gmail.com>
Some drivers implementing NCM-like protocols, may re-use those functions, as is
the case in the huawei_cdc_ncm driver.
Export them via EXPORT_SYMBOL_GPL, in accordance with how other functions have
been exported.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
---
drivers/net/usb/cdc_ncm.c | 6 ++++--
include/linux/usb/cdc_ncm.h | 3 +++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 43afde8..62686be 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -858,7 +858,7 @@ static void cdc_ncm_txpath_bh(unsigned long param)
}
}
-static struct sk_buff *
+struct sk_buff *
cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
{
struct sk_buff *skb_out;
@@ -885,6 +885,7 @@ error:
return NULL;
}
+EXPORT_SYMBOL_GPL(cdc_ncm_tx_fixup);
/* verify NTB header and return offset of first NDP, or negative error */
int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in)
@@ -965,7 +966,7 @@ error:
}
EXPORT_SYMBOL_GPL(cdc_ncm_rx_verify_ndp16);
-static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
+int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
{
struct sk_buff *skb;
struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
@@ -1040,6 +1041,7 @@ err_ndp:
error:
return 0;
}
+EXPORT_SYMBOL_GPL(cdc_ncm_rx_fixup);
static void
cdc_ncm_speed_change(struct cdc_ncm_ctx *ctx,
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index cc25b70..163244b 100644
--- a/include/linux/usb/cdc_ncm.h
+++ b/include/linux/usb/cdc_ncm.h
@@ -133,3 +133,6 @@ extern void cdc_ncm_unbind(struct usbnet *dev, struct usb_interface *intf);
extern struct sk_buff *cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct sk_buff *skb, __le32 sign);
extern int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in);
extern int cdc_ncm_rx_verify_ndp16(struct sk_buff *skb_in, int ndpoffset);
+struct sk_buff *
+cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags);
+int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in);
--
1.7.10.4
^ permalink raw reply related
* [PATCH RESEND net-next V2 0/3] huawei_cdc_ncm introduction
From: Enrico Mioso @ 2013-08-22 2:30 UTC (permalink / raw)
To: gregkh, oliver, linux-usb, netdev, linux-kernel; +Cc: Enrico Mioso
These patches are all related to the new huawei_cdc_ncm driver, supporting
devices that use the NCM protocol as a transport layer for other protocols.
this is the case of the Huawei E3131 3G modem.
Thanks should go to bjorn and others who helped me with patience.
Enrico Mioso (3):
net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
net: huawei_cdc_ncm: Introduce the
net: cdc_ncm: remove non-standard NCM device IDs
drivers/net/usb/Kconfig | 11 +++++++++++
drivers/net/usb/Makefile | 1 +
drivers/net/usb/cdc_ncm.c | 17 ++++-------------
include/linux/usb/cdc_ncm.h | 3 +++
4 files changed, 19 insertions(+), 13 deletions(-)
--
This version includes mainly cosmetic fixes related to patches.
1.7.10.4
^ permalink raw reply
* Re: [PATCH] netns: unix: only allow to find out unix socket in same net namespace
From: Gao feng @ 2013-08-22 1:36 UTC (permalink / raw)
To: Eric W. Biederman
Cc: netdev, systemd-devel, lxc-devel, davem, Linux Containers,
libvir-list@redhat.com
In-Reply-To: <87haejtjet.fsf@xmission.com>
On 08/21/2013 06:42 PM, Eric W. Biederman wrote:
> Gao feng <gaofeng@cn.fujitsu.com> writes:
>
>> right now I only take note of the unix socket /run/systemd/private,
>> but there may have many similar unix sockets, they can exist in any
>> path. the strange problems will still happen.
>
> It could just as easily have been a fifo in the filesystem, and the
> result would have been the same.
>
> The network namespace are all about communicating between network
> namespaces and that is what was allowed here.
>
> If you don't want a socket or a fifo or any other file to be used by a
> container don't give it access to it. It really is that simple.
>
Hmm, I tend to think you are right...
Thanks!
^ permalink raw reply
* Re: [PATCH net-next] tcp: increase throughput when reordering is high
From: Neal Cardwell @ 2013-08-22 2:18 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: David Miller, Eric Dumazet, Netdev
In-Reply-To: <1377131363-31341-1-git-send-email-ycheng@google.com>
On Wed, Aug 21, 2013 at 8:29 PM, Yuchung Cheng <ycheng@google.com> wrote:
> The stack currently detects reordering and avoid spurious
> retransmission very well. However the throughput is sub-optimal under
> high reordering because cwnd is increased only if the data is deliverd
> in order. I.e., FLAG_DATA_ACKED check in tcp_ack(). The more packet
> are reordered the worse the throughput is.
>
> Therefore when reordering is proven high, cwnd should advance whenever
> the data is delivered regardless of its ordering. If reordering is low,
> conservatively advance cwnd only on ordered deliveries in Open state,
> and retain cwnd in Disordered state (RFC5681).
>
> Using netperf on a qdisc setup of 20Mbps BW and random RTT from 45ms
> to 55ms (for reordering effect). This change increases TCP throughput
> by 20 - 25% to near bottleneck BW.
>
> A special case is the stretched ACK with new SACK and/or ECE mark.
> For example, a receiver may receive an out of order or ECN packet with
> unacked data buffered because of LRO or delayed ACK. The principle on
> such an ACK is to advance cwnd on the cummulative acked part first,
> then reduce cwnd in tcp_fastretrans_alert().
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> ---
> net/ipv4/tcp_input.c | 32 ++++++++++++++++++++------------
> 1 file changed, 20 insertions(+), 12 deletions(-)
Acked-by: Neal Cardwell <ncardwell@google.com>
neal
^ permalink raw reply
* [PATCH 2/2] ethernet: broadcom: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-08-22 1:57 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Maxime Bizon', 'Florian Fainelli',
'Jingoo Han'
In-Reply-To: <001901ce9eda$a9351310$fb9f3930$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index b1bcd4b..ca963d4 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -2836,7 +2836,6 @@ static int bcm_enetsw_remove(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(res->start, resource_size(res));
- platform_set_drvdata(pdev, NULL);
free_netdev(dev);
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] ethernet: moxa: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-08-22 1:55 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jonas Jensen', 'Jingoo Han'
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/moxa/moxart_ether.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index 6eee686..83c2091 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -533,7 +533,6 @@ static int moxart_remove(struct platform_device *pdev)
unregister_netdev(ndev);
free_irq(ndev->irq, ndev);
moxart_mac_free_memory(ndev);
- platform_set_drvdata(pdev, NULL);
free_netdev(ndev);
return 0;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH V3] ipv6: handle Redirect ICMP Message with no Redirected Header option
From: Duan Jiong @ 2013-08-22 1:28 UTC (permalink / raw)
To: hannes; +Cc: davem, netdev
In-Reply-To: <20130821111700.GE20223@order.stressinduktion.org>
于 2013年08月21日 19:17, Hannes Frederic Sowa 写道:
> On Wed, Aug 21, 2013 at 03:14:12PM +0800, Duan Jiong wrote:
>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>
>> rfc 4861 says the Redirected Header option is optional, so
>> the kernel should not drop the Redirect Message that has no
>> Redirected Header option. In this patch, the function
>> ip6_redirect_no_header() is introduced to deal with that
>> condition.
>>
>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>
> Sorry for being so picky about local socket delivery before. You were right
> all along.
>
> I just tested and reviewed this patch and everything is fine:
>
> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>
> Just out of curiosity, can you tell because of which devices you did
> this patch?
In fact, i did this patch just because i want to learn more about the
ipv6 implemention.
^ permalink raw reply
* Re: Very Urgent!!!
From: Doris Omar @ 2013-08-22 1:12 UTC (permalink / raw)
Greetings from BURKINA FASO:
Let me start by introduce myself,I am Mrs Doris Omar, BILL AND EXCHANGE MANAGER (Bank of Africa) Ouagadougou, Burkina Faso.I am writting you this letter based on the latest development at our bank which I will like to bring to your personal edification. $12,250million transfer claims. this is a legitimate transaction and I agreed to offer you 40% of this money as my foreign partner after confirmation of the fund in your bank account,If you are interested, please get back to me.
Yours faithful,
Mrs Doris Omar.
^ permalink raw reply
* Re: [PATCH net] skge: dma_sync the whole receive buffer
From: Greg KH @ 2013-08-22 0:40 UTC (permalink / raw)
To: poma; +Cc: Stephen Hemminger, David Miller, netdev, Linus Torvalds
In-Reply-To: <5214E4FB.7010208@gmail.com>
On Wed, Aug 21, 2013 at 06:04:11PM +0200, poma wrote:
> Signor Greg you are supposed to be very resourceful guy, especially in
> matters concerning the hardware, so please if you can set aside your
> valuable time and help us finally resolve this issue.
Please take it up with Stephen, it's his driver, not mine.
greg k-h
^ permalink raw reply
* [PATCH net-next] tcp: increase throughput when reordering is high
From: Yuchung Cheng @ 2013-08-22 0:29 UTC (permalink / raw)
To: davem, ncardwell, edumazet; +Cc: netdev, Yuchung Cheng
The stack currently detects reordering and avoid spurious
retransmission very well. However the throughput is sub-optimal under
high reordering because cwnd is increased only if the data is deliverd
in order. I.e., FLAG_DATA_ACKED check in tcp_ack(). The more packet
are reordered the worse the throughput is.
Therefore when reordering is proven high, cwnd should advance whenever
the data is delivered regardless of its ordering. If reordering is low,
conservatively advance cwnd only on ordered deliveries in Open state,
and retain cwnd in Disordered state (RFC5681).
Using netperf on a qdisc setup of 20Mbps BW and random RTT from 45ms
to 55ms (for reordering effect). This change increases TCP throughput
by 20 - 25% to near bottleneck BW.
A special case is the stretched ACK with new SACK and/or ECE mark.
For example, a receiver may receive an out of order or ECN packet with
unacked data buffered because of LRO or delayed ACK. The principle on
such an ACK is to advance cwnd on the cummulative acked part first,
then reduce cwnd in tcp_fastretrans_alert().
Signed-off-by: Yuchung Cheng <ycheng@google.com>
---
net/ipv4/tcp_input.c | 32 ++++++++++++++++++++------------
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e965cc7..ec492ea 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2485,8 +2485,6 @@ static void tcp_try_to_open(struct sock *sk, int flag, const int prior_unsacked)
if (inet_csk(sk)->icsk_ca_state != TCP_CA_CWR) {
tcp_try_keep_open(sk);
- if (inet_csk(sk)->icsk_ca_state != TCP_CA_Open)
- tcp_moderate_cwnd(tp);
} else {
tcp_cwnd_reduction(sk, prior_unsacked, 0);
}
@@ -3128,11 +3126,24 @@ static inline bool tcp_ack_is_dubious(const struct sock *sk, const int flag)
inet_csk(sk)->icsk_ca_state != TCP_CA_Open;
}
+/* Decide wheather to run the increase function of congestion control. */
static inline bool tcp_may_raise_cwnd(const struct sock *sk, const int flag)
{
- const struct tcp_sock *tp = tcp_sk(sk);
- return (!(flag & FLAG_ECE) || tp->snd_cwnd < tp->snd_ssthresh) &&
- !tcp_in_cwnd_reduction(sk);
+ if (tcp_in_cwnd_reduction(sk))
+ return false;
+
+ /* If reordering is high then always grow cwnd whenever data is
+ * delivered regardless of its ordering. Otherwise stay conservative
+ * and only grow cwnd on in-order delivery in Open state, and retain
+ * cwnd in Disordered state (RFC5681). A stretched ACK with
+ * new SACK or ECE mark may first advance cwnd here and later reduce
+ * cwnd in tcp_fastretrans_alert() based on more states.
+ */
+ if (tcp_sk(sk)->reordering > sysctl_tcp_reordering)
+ return flag & FLAG_FORWARD_PROGRESS;
+
+ return inet_csk(sk)->icsk_ca_state == TCP_CA_Open &&
+ flag & FLAG_DATA_ACKED;
}
/* Check that window update is acceptable.
@@ -3352,18 +3363,15 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
flag |= tcp_clean_rtx_queue(sk, prior_fackets, prior_snd_una, sack_rtt);
acked -= tp->packets_out;
+ /* Advance cwnd if state allows */
+ if (tcp_may_raise_cwnd(sk, flag))
+ tcp_cong_avoid(sk, ack, prior_in_flight);
+
if (tcp_ack_is_dubious(sk, flag)) {
- /* Advance CWND, if state allows this. */
- if ((flag & FLAG_DATA_ACKED) && tcp_may_raise_cwnd(sk, flag))
- tcp_cong_avoid(sk, ack, prior_in_flight);
is_dupack = !(flag & (FLAG_SND_UNA_ADVANCED | FLAG_NOT_DUP));
tcp_fastretrans_alert(sk, acked, prior_unsacked,
is_dupack, flag);
- } else {
- if (flag & FLAG_DATA_ACKED)
- tcp_cong_avoid(sk, ack, prior_in_flight);
}
-
if (tp->tlp_high_seq)
tcp_process_tlp_ack(sk, ack, flag);
--
1.8.3
^ permalink raw reply related
* Re: Pull request: sfc 2013-08-21
From: Ben Hutchings @ 2013-08-21 23:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1377128568.634.5.camel@bwh-desktop.uk.level5networks.com>
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
[Re-sending with the proper cc's and a signature.]
The following changes since commit 0f7dd1aa8f959216f1faa71513b9d3c1a9065e5a:
Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux (2013-08-16 10:00:18 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc.git sfc-3.11
for you to fetch changes up to f3851b0acc5a75bd33c6d344a2e4f920e1622ff0:
sfc: Fix lookup of default RX MAC filters when steered using ethtool (2013-08-21 14:18:12 +0100)
Just a single fix for 3.11 (and 3.10-stable).
Ben.
----------------------------------------------------------------
Ben Hutchings (1):
sfc: Fix lookup of default RX MAC filters when steered using ethtool
drivers/net/ethernet/sfc/filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Fw: [Bug 60779] New: tcp_fastretrans_alert triggered on tcp_input.c
From: Stephen Hemminger @ 2013-08-21 23:44 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Wed, 21 Aug 2013 15:55:49 -0700
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 60779] New: tcp_fastretrans_alert triggered on tcp_input.c
https://bugzilla.kernel.org/show_bug.cgi?id=60779
Bug ID: 60779
Summary: tcp_fastretrans_alert triggered on tcp_input.c
Product: Networking
Version: 2.5
Kernel Version: 3.10.7
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: shemminger@linux-foundation.org
Reporter: otavio.n.cipriani@gmail.com
Regression: No
Created attachment 107276
--> https://bugzilla.kernel.org/attachment.cgi?id=107276&action=edit
Call trace
Unfortunately I do not know how to reproduce the bug. Nothing seems to be
affected.
The only parameters I changed were:
net.core.rmem_max = 4194304;
net.core.wmem_max = 1048576.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [PATCH net] sfc: Fix lookup of default RX MAC filters when steered using ethtool
From: Ben Hutchings @ 2013-08-21 23:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1377128568.634.5.camel@bwh-desktop.uk.level5networks.com>
commit 385904f819e3 ('sfc: Don't use
efx_filter_{build,hash,increment}() for default MAC filters') used the
wrong name to find the index of default RX MAC filters at insertion/
update time. This could result in memory corruption and would in any
case silently fail to update the filter.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/ethernet/sfc/filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/filter.c b/drivers/net/ethernet/sfc/filter.c
index 2a469b2..30d7442 100644
--- a/drivers/net/ethernet/sfc/filter.c
+++ b/drivers/net/ethernet/sfc/filter.c
@@ -675,7 +675,7 @@ s32 efx_filter_insert_filter(struct efx_nic *efx, struct efx_filter_spec *spec,
BUILD_BUG_ON(EFX_FILTER_INDEX_UC_DEF != 0);
BUILD_BUG_ON(EFX_FILTER_INDEX_MC_DEF !=
EFX_FILTER_MC_DEF - EFX_FILTER_UC_DEF);
- rep_index = spec->type - EFX_FILTER_INDEX_UC_DEF;
+ rep_index = spec->type - EFX_FILTER_UC_DEF;
ins_index = rep_index;
spin_lock_bh(&state->lock);
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: [PATCH 0/2] fix generic netlink locking issue(s)
From: Pravin Shelar @ 2013-08-21 22:53 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: Johannes Berg, netdev, Thomas Graf
In-Reply-To: <52150F87.90207@hartkopp.net>
This looks like more general problem and not specific to genl_ctrl
family. I have couple of fixes for issues you are seeing, I will send
out those patches soon.
On Wed, Aug 21, 2013 at 12:05 PM, Oliver Hartkopp
<socketcan@hartkopp.net> wrote:
> On 21.08.2013 16:08, Johannes Berg wrote:
>> Here's another attempt at fixing the genetlink locking issue,
>> hopefully better tested this time. Sorry about the mess the
>> previous version caused.
>>
>> I really didn't find a way to "simply" add locking, no matter
>> which way I turn genetlink is special because it would then use
>> the same locks "inside" and "outside" the generic netlink family;
>> "inside" because I'm trying to protect the otherwise unlocked
>> dump call, and "outside" because it itself is a generic netlink
>> family so needs to protect things there.
>>
>> As a result, I've turned to RCU and (hopefully) made it safe.
>> The unregistration can get fairly expensive with all the calls
>> to synchronize_rcu(), but I don't see any better way, and it's
>> hopefully really rare.
>>
>> The only place that now uses RCU is ctrl_dumpfamily(), but it'd
>> be possible to use it in other places. I didn't want to do it
>> in this patch, but I also don't see any candidates where that
>> would really make sense.
>>
>> The first patch should obviously go into 3.11, I'll let you
>> decide about the second. This one might actually be easier to
>> backport than the original one, but it'd still have to be done
>> carefully.
>
> I applied both patches.
> The lockdep issue vanished and i still can write emails :-)
>
> Thanks Johannes.
>
> Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
>
>>
>> johannes
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH linux-next] ipv6: fix missing braces in ip6_tnl_add_linklocal
From: Vincent Stehlé @ 2013-08-21 22:19 UTC (permalink / raw)
To: netdev, linux-kernel, linux-next
Cc: Vincent Stehlé, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Ding Tianhong
Braces have been removed by mistake by commit df8372c 'ipv6: fix checkpatch
errors in net/ipv6/addrconf.c'.
This fixes the following compilation warning:
net/ipv6/addrconf.c: In function ‘addrconf_notify’:
net/ipv6/addrconf.c:2793:22: warning: ‘link_dev’ may be used uninitialized in this function [-Wmaybe-uninitialized]
net/ipv6/addrconf.c:2802:21: note: ‘link_dev’ was declared here
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: David S. Miller <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Ding Tianhong <dingtianhong@huawei.com>
---
Hi,
This can be seen in e.g. Linux next-20130821.
Best regards,
V.
net/ipv6/addrconf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 980aa98..b2f2e6d 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2803,10 +2803,11 @@ static void ip6_tnl_add_linklocal(struct inet6_dev *idev)
struct net *net = dev_net(idev->dev);
/* first try to inherit the link-local address from the link device */
- if (idev->dev->iflink)
+ if (idev->dev->iflink) {
link_dev = __dev_get_by_index(net, idev->dev->iflink);
if (link_dev && !ipv6_inherit_linklocal(idev, link_dev))
return;
+ }
/* then try to inherit it from any device */
for_each_netdev(net, link_dev) {
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] SolutionEngine7724: fix typo in Ether platform data
From: Sergei Shtylyov @ 2013-08-21 22:18 UTC (permalink / raw)
To: netdev, lethal, linux-sh, davem
In-Reply-To: <201308220215.16463.sergei.shtylyov@cogentembedded.com>
Commit bd61224b1cbec096694e89c4187119c8576fe186 (SolutionEngine7724: fix Ether
support) has a typo in the 'phy_interface' field name of the platform data which
causes build error -- fix it.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/sh/boards/mach-se/7724/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net-next/arch/sh/boards/mach-se/7724/setup.c
===================================================================
--- net-next.orig/arch/sh/boards/mach-se/7724/setup.c
+++ net-next/arch/sh/boards/mach-se/7724/setup.c
@@ -377,7 +377,7 @@ static struct resource sh_eth_resources[
static struct sh_eth_plat_data sh_eth_plat = {
.phy = 0x1f, /* SMSC LAN8187 */
.edmac_endian = EDMAC_LITTLE_ENDIAN,
- .phy_interace = PHY_INTERFACE_MODE_MII,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
};
static struct platform_device sh_eth_device = {
^ permalink raw reply
* [PATCH 1/2] SH7619: fix typo in Ether platform data
From: Sergei Shtylyov @ 2013-08-21 22:17 UTC (permalink / raw)
To: netdev, lethal, linux-sh, davem
In-Reply-To: <201308220215.16463.sergei.shtylyov@cogentembedded.com>
Commit 06a64f91da72cb5827e2bedef2ead60a123fd66e (SH7619: fix Ether support) has
a typo in the 'phy_interface' field name of the platform data which causes build
error -- fix it.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/sh/kernel/cpu/sh2/setup-sh7619.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net-next/arch/sh/kernel/cpu/sh2/setup-sh7619.c
===================================================================
--- net-next.orig/arch/sh/kernel/cpu/sh2/setup-sh7619.c
+++ net-next/arch/sh/kernel/cpu/sh2/setup-sh7619.c
@@ -114,7 +114,7 @@ static struct platform_device scif2_devi
static struct sh_eth_plat_data eth_platform_data = {
.phy = 1,
.edmac_endian = EDMAC_LITTLE_ENDIAN,
- .phy_interace = PHY_INTERFACE_MODE_MII,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
};
static struct resource eth_resources[] = {
^ 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