* Re: [PATCH v3 net-next] tcp: TSO packets automatic sizing
From: David Miller @ 2013-08-29 20:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ncardwell, ycheng, vanj, therbert
In-Reply-To: <1377807977.8277.40.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 29 Aug 2013 13:26:17 -0700
> Typical bufferbloat at the end of transfert :
>
> [ 4547.051521] TCP: sk ffff88085825d180 cwnd 327 packets 3 rate 7575936000/srtt 1581
> [ 4547.052722] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 198 sack_rtt 4294967295
> [ 4547.052726] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 198 srtt 1581
> [ 4547.052729] TCP: sk ffff88085825d180 cwnd 327 packets 1 rate 7575936000/srtt 1582
> [ 4547.053315] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 198 sack_rtt 4294967295
> [ 4547.053318] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 198 srtt 1582
> [ 4547.053321] TCP: sk ffff88085825d180 cwnd 327 packets 0 rate 7575936000/srtt 1583
>
> Maybe we could instead store a value corrected by the sk_pacing_rate
>
> rate = (big_cwin * mss) / big_srtt
>
> stored_rtt = rate / (big_cwin * mss)
No objections from me.
^ permalink raw reply
* Re: [PATCH] xgmac: use bufsz not dma_buf_sz in rx_refill
From: Kyle McMartin @ 2013-08-29 20:35 UTC (permalink / raw)
To: David Miller; +Cc: rob.herring, netdev
In-Reply-To: <20130829.163437.1817937756134021051.davem@davemloft.net>
On Thu, Aug 29, 2013 at 04:34:37PM -0400, David Miller wrote:
> From: Kyle McMartin <kyle@redhat.com>
> Date: Thu, 29 Aug 2013 16:11:51 -0400
>
> > Noticed while debugging another issue that DMA debug turned up, looks
> > like commit ef468d23 missed a case when switching to bufsz instead of
> > priv->dma_buf_sz? (tbf, the whole handling of DMA buffers seems slightly
> > suspect since we're not tracking the size, but trusting the hardware
> > between map and unmap...)
> >
> > Signed-off-by: Kyle McMartin <kyle@redhat.com>
>
> Applied and queued up for -stable, thanks.
Heh, too fast David, Rob nak'd it. :)
Sorry about that.
--Kyle
^ permalink raw reply
* Re: [PATCH] xgmac: use bufsz not dma_buf_sz in rx_refill
From: David Miller @ 2013-08-29 20:34 UTC (permalink / raw)
To: kyle; +Cc: rob.herring, netdev
In-Reply-To: <20130829201151.GJ8764@redacted.bos.redhat.com>
From: Kyle McMartin <kyle@redhat.com>
Date: Thu, 29 Aug 2013 16:11:51 -0400
> Noticed while debugging another issue that DMA debug turned up, looks
> like commit ef468d23 missed a case when switching to bufsz instead of
> priv->dma_buf_sz? (tbf, the whole handling of DMA buffers seems slightly
> suspect since we're not tracking the size, but trusting the hardware
> between map and unmap...)
>
> Signed-off-by: Kyle McMartin <kyle@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] xgmac: use bufsz not dma_buf_sz in rx_refill
From: Rob Herring @ 2013-08-29 20:24 UTC (permalink / raw)
To: Kyle McMartin; +Cc: netdev
In-Reply-To: <20130829201151.GJ8764@redacted.bos.redhat.com>
On 08/29/2013 03:11 PM, Kyle McMartin wrote:
> Noticed while debugging another issue that DMA debug turned up, looks
> like commit ef468d23 missed a case when switching to bufsz instead of
> priv->dma_buf_sz? (tbf, the whole handling of DMA buffers seems slightly
> suspect since we're not tracking the size, but trusting the hardware
> between map and unmap...)
Please see my patch series of fixes:
http://www.spinics.net/lists/netdev/msg248076.html
> Signed-off-by: Kyle McMartin <kyle@redhat.com>
>
> --- a/drivers/net/ethernet/calxeda/xgmac.c
> +++ b/drivers/net/ethernet/calxeda/xgmac.c
> @@ -686,7 +686,7 @@ static void xgmac_rx_refill(struct xgmac_priv *priv)
> priv->rx_skbuff[entry] = skb;
> paddr = dma_map_single(priv->device, skb->data,
> bufsz, DMA_FROM_DEVICE);
> - desc_set_buf_addr(p, paddr, priv->dma_buf_sz);
> + desc_set_buf_addr(p, paddr, bufsz);
This is not right because the h/w wants the size to include the 2 bytes
skipped at the beginning for NET_IP_ALIGN. The h/w may also corrupt 1-7
bytes of data at the head or tail if the frame is not 8 byte aligned and
padded. We are relying that skb allocations are aligned.
Rob
^ permalink raw reply
* Re: [PATCH] xgmac: use bufsz not dma_buf_sz in rx_refill
From: Sergei Shtylyov @ 2013-08-29 20:31 UTC (permalink / raw)
To: Kyle McMartin; +Cc: rob.herring, netdev
In-Reply-To: <20130829201151.GJ8764@redacted.bos.redhat.com>
Hello.
On 08/30/2013 12:11 AM, Kyle McMartin wrote:
> Noticed while debugging another issue that DMA debug turned up, looks
> like commit ef468d23 missed a case when switching to bufsz instead of
Please also specify that commit's summary line in parens.
> priv->dma_buf_sz? (tbf, the whole handling of DMA buffers seems slightly
> suspect since we're not tracking the size, but trusting the hardware
> between map and unmap...)
> Signed-off-by: Kyle McMartin <kyle@redhat.com>
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] sh_eth: no need to call ether_setup()
From: Sergei Shtylyov @ 2013-08-29 20:29 UTC (permalink / raw)
To: netdev; +Cc: nobuhiro.iwamatsu.yj, linux-sh
In-Reply-To: <201308300024.48415.sergei.shtylyov@cogentembedded.com>
Hello.
On 08/30/2013 12:24 AM, Sergei Shtylyov wrote:
> There's no need to call ether_setup() in the driver since prior alloc_etherdev()
> call already arranges for it.
> Suggested-by: Denis Kirjanov <kda@linux-powerpc.org>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> ---
Sorry, forgot to mention the patch is against the 'net-next.git' repo. :-/
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v3 net-next] tcp: TSO packets automatic sizing
From: Eric Dumazet @ 2013-08-29 20:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, ncardwell, ycheng, vanj, therbert
In-Reply-To: <20130829.155131.1753610025310087003.davem@davemloft.net>
On Thu, 2013-08-29 at 15:51 -0400, David Miller wrote:
> Applied, please post a new copy of your accompanying packet scheduler.
>
> Thanks.
Thanks David.
I am a bit puzzled by the caching of srtt in tcp metrics. We ten to
cache bufferbloated values that are almost useless.
On this 50ms RTT link, the syn/synack rtt was correctly sampled at 51
jiffies, but tcp_init_metrics() finds a very high srtt cached from
previous tcp flow, which ended its life with a huge cwin=327/srtt=1468
because of bufferbloat.
Since the new connexion starts with IW10, the estimated rate is slightly
wrong for the first ~10 incoming acks, before ewma converges to the
right value...
[ 4544.656476] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 51 sack_rtt 4294967295
[ 4544.656482] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 51 srtt 0
[ 4544.656496] TCP: sk ffff88085825d180 cwnd 10 packets 0 rate 231680000/srtt 408
[ 4544.707045] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 50 sack_rtt 4294967295
[ 4544.707051] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 50 srtt 1468
[ 4544.707055] TCP: sk ffff88085825d180 cwnd 11 packets 9 rate 254848000/srtt 1335
[ 4544.707067] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 50 sack_rtt 4294967295
[ 4544.707069] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 50 srtt 1335
[ 4544.707071] TCP: sk ffff88085825d180 cwnd 12 packets 10 rate 278016000/srtt 1219
[ 4544.707694] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 51 sack_rtt 4294967295
[ 4544.707699] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 51 srtt 1219
[ 4544.707703] TCP: sk ffff88085825d180 cwnd 13 packets 11 rate 301184000/srtt 1118
[ 4544.708324] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 52 sack_rtt 4294967295
[ 4544.708330] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 52 srtt 1118
[ 4544.708333] TCP: sk ffff88085825d180 cwnd 14 packets 12 rate 324352000/srtt 1031
[ 4544.708846] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 52 sack_rtt 4294967295
[ 4544.708851] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 52 srtt 1031
[ 4544.708855] TCP: sk ffff88085825d180 cwnd 15 packets 13 rate 347520000/srtt 955
[ 4544.709521] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 53 sack_rtt 4294967295
[ 4544.709526] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 53 srtt 955
[ 4544.709530] TCP: sk ffff88085825d180 cwnd 16 packets 14 rate 370688000/srtt 889
[ 4544.710103] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 53 sack_rtt 4294967295
[ 4544.710108] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 53 srtt 889
[ 4544.710111] TCP: sk ffff88085825d180 cwnd 17 packets 15 rate 393856000/srtt 831
[ 4544.710683] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 54 sack_rtt 4294967295
[ 4544.710688] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 54 srtt 831
[ 4544.710691] TCP: sk ffff88085825d180 cwnd 18 packets 16 rate 417024000/srtt 782
[ 4544.711210] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 55 sack_rtt 4294967295
[ 4544.711215] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 55 srtt 782
[ 4544.711219] TCP: sk ffff88085825d180 cwnd 19 packets 17 rate 440192000/srtt 740
[ 4544.711868] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 55 sack_rtt 4294967295
[ 4544.711873] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 55 srtt 740
[ 4544.711876] TCP: sk ffff88085825d180 cwnd 20 packets 18 rate 463360000/srtt 703
[ 4544.757576] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 51 sack_rtt 4294967295
[ 4544.757581] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 51 srtt 703
[ 4544.757585] TCP: sk ffff88085825d180 cwnd 21 packets 19 rate 486528000/srtt 667
[ 4544.757595] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 51 sack_rtt 4294967295
[ 4544.757597] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 51 srtt 667
[ 4544.757610] TCP: sk ffff88085825d180 cwnd 22 packets 20 rate 509696000/srtt 635
[ 4544.773527] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 67 sack_rtt 4294967295
[ 4544.773533] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 67 srtt 635
[ 4544.773536] TCP: sk ffff88085825d180 cwnd 23 packets 21 rate 532864000/srtt 623
[ 4544.773548] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 67 sack_rtt 4294967295
[ 4544.773560] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 67 srtt 623
[ 4544.773562] TCP: sk ffff88085825d180 cwnd 24 packets 22 rate 556032000/srtt 613
[ 4544.778208] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 71 sack_rtt 4294967295
[ 4544.778213] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 71 srtt 613
[ 4544.778216] TCP: sk ffff88085825d180 cwnd 25 packets 23 rate 579200000/srtt 608
[ 4544.778237] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 71 sack_rtt 4294967295
[ 4544.778238] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 71 srtt 608
[ 4544.778240] TCP: sk ffff88085825d180 cwnd 26 packets 24 rate 602368000/srtt 603
[ 4544.782776] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 74 sack_rtt 4294967295
[ 4544.782781] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 74 srtt 603
[ 4544.782785] TCP: sk ffff88085825d180 cwnd 27 packets 25 rate 625536000/srtt 602
[ 4544.782795] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 74 sack_rtt 4294967295
[ 4544.782808] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 74 srtt 602
...
Typical bufferbloat at the end of transfert :
[ 4547.051521] TCP: sk ffff88085825d180 cwnd 327 packets 3 rate 7575936000/srtt 1581
[ 4547.052722] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 198 sack_rtt 4294967295
[ 4547.052726] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 198 srtt 1581
[ 4547.052729] TCP: sk ffff88085825d180 cwnd 327 packets 1 rate 7575936000/srtt 1582
[ 4547.053315] TCP: tcp_ack_update_rtt sk ffff88085825d180 seq_rtt 198 sack_rtt 4294967295
[ 4547.053318] TCP: tcp_rtt_estimator sk ffff88085825d180 mrtt 198 srtt 1582
[ 4547.053321] TCP: sk ffff88085825d180 cwnd 327 packets 0 rate 7575936000/srtt 1583
Maybe we could instead store a value corrected by the sk_pacing_rate
rate = (big_cwin * mss) / big_srtt
stored_rtt = rate / (big_cwin * mss)
^ permalink raw reply
* Re: [PATCH] xgmac: use bufsz not dma_buf_sz in rx_refill
From: Kyle McMartin @ 2013-08-29 20:26 UTC (permalink / raw)
To: Rob Herring; +Cc: netdev
In-Reply-To: <521FADFE.7040908@calxeda.com>
On Thu, Aug 29, 2013 at 03:24:30PM -0500, Rob Herring wrote:
> On 08/29/2013 03:11 PM, Kyle McMartin wrote:
> > Noticed while debugging another issue that DMA debug turned up, looks
> > like commit ef468d23 missed a case when switching to bufsz instead of
> > priv->dma_buf_sz? (tbf, the whole handling of DMA buffers seems slightly
> > suspect since we're not tracking the size, but trusting the hardware
> > between map and unmap...)
>
> Please see my patch series of fixes:
>
> http://www.spinics.net/lists/netdev/msg248076.html
>
Hah, thanks. Yeah, I wondered wtf was up with get_buf_len, but figured
the hardware must have been doing something subtle. ;-)
I'll apply these to our Fedora tree and pass them along for testing.
Thanks Rob.
--Kyle
^ permalink raw reply
* [PATCH] sh_eth: no need to call ether_setup()
From: Sergei Shtylyov @ 2013-08-29 20:24 UTC (permalink / raw)
To: netdev; +Cc: nobuhiro.iwamatsu.yj, linux-sh
There's no need to call ether_setup() in the driver since prior alloc_etherdev()
call already arranges for it.
Suggested-by: Denis Kirjanov <kda@linux-powerpc.org>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 3 ---
1 file changed, 3 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -2639,9 +2639,6 @@ static int sh_eth_drv_probe(struct platf
SET_NETDEV_DEV(ndev, &pdev->dev);
- /* Fill in the fields of the device structure with ethernet values. */
- ether_setup(ndev);
-
mdp = netdev_priv(ndev);
mdp->num_tx_ring = TX_RING_SIZE;
mdp->num_rx_ring = RX_RING_SIZE;
^ permalink raw reply
* Re: [PATCH net-next v4 0/13] bonding: remove vlan special handling
From: David Miller @ 2013-08-29 20:20 UTC (permalink / raw)
To: vfalico
Cc: netdev, vyasevic, fubar, andy, edumazet, jiri, alexander.h.duyck,
amwang
In-Reply-To: <1377725116-31126-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Wed, 28 Aug 2013 23:25:03 +0200
> The aim of this patchset is to remove bondings' own vlan handling as much
> as possible and replace it with the netdev upper device functionality.
>
> The upper device functionality is extended to include also lower devices
> and to have, for each device, a full view of every lower and upper device,
> but not only the first-level ones. This might permit in the future to
> avoid, for any grouping/teaming/upper/lower devices, to maintain its own
> lists of slaves/vlans/etc.
>
> This is achieved by adding a helper function to upper dev list handling -
> netdev_upper_get_next_dev(dev, iter), which returns the next device after
> the list_head **iter, and sets *iter to the next list_head *. This patchset
> also adds netdev_for_each_upper_dev(dev, upper, iter), which iterates
> through the whole dev->upper_dev_list, setting upper to the net_device.
> The only special treatment of vlans remains in rlb code.
>
> This patchset solves several issues with bonding, simplifies it overall,
> RCUify further and exports upper list functions for any other users which
> might also want to get rid of its own vlan_lists or slaves.
>
> I'm testing it continuously currently, no issues found, will update on
> anything.
I like these changes a lot, nice work.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/2] sh_eth: Fix cache invalidation omission of receive buffer
From: David Miller @ 2013-08-29 20:15 UTC (permalink / raw)
To: horms+renesas
Cc: netdev, linux-sh, magnus.damm, sergei.shtylyov, kouei.abe.cp
In-Reply-To: <1377650589-20960-2-git-send-email-horms+renesas@verge.net.au>
From: Simon Horman <horms+renesas@verge.net.au>
Date: Wed, 28 Aug 2013 09:43:08 +0900
> From: Kouei Abe <kouei.abe.cp@renesas.com>
>
> Signed-off-by: Kouei Abe <kouei.abe.cp@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> drivers/net/ethernet/renesas/sh_eth.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index c357076..f386a8f 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -1342,6 +1342,8 @@ static int sh_eth_rx(struct net_device *ndev, u32 intr_status, int *quota)
> mdp->rx_skbuff[entry] = NULL;
> if (mdp->cd->rpadir)
> skb_reserve(skb, NET_IP_ALIGN);
> + dma_sync_single_for_cpu(&ndev->dev, rxdesc->addr,
> + mdp->rx_buf_sz, DMA_FROM_DEVICE);
Please indent the second line of the dma sync call properly.
The arguments should start at the first column after the openning
parenthesis of the function call on the first line, using the
appropriate number of TAB then space characters (as needed).
Thanks.
^ permalink raw reply
* Re: [net-next v2 00/10][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2013-08-29 20:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1377773406-24851-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 29 Aug 2013 03:49:56 -0700
> This series contains updates to ixgbe.
>
> Jacob provides a fix for 82599 devices where it can potentially keep link
> lights up when the adapter has gone down.
>
> Mark provides a fix to resolve the possible use of uninitialized memory
> by checking the return value on EEPROM reads.
>
> Don provides 2 patches, one to fix a issue where we were traversing the
> Tx ring with the value of IXGBE_NUM_RX_QUEUES which currently happens
> to have the correct value but this is misleading. A change later, could
> easily make this no longer correct so when traversing the Tx ring, use
> netdev->num_tx_queues. His second patch does some minor clean ups of log
> messages.
>
> Emil provides the remaining ixgbe patches. First he fixes the link test
> where forcing the laser before the link check can lead to inconsistent
> results because it does not guarantee that the link will be negotiated
> correctly. Then he initializes the message buffer array to 0 in order
> to avoid using random numbers from the memory as a MAC address for the
> VF. Emil also fixes the read loop for the I2C data to account for the
> offset for SFP+ modules. Lastly, Emil provides several patches to add
> support for QSFP modules where 1Gbps support is added as well as support
> for older QSFP active direct attach cables which pre-date SFF-8436 v3.6.
>
> v2: Fixed patch 4 description and added blank line based on feedback from
> Sergei Shtylyov
Pulled, thanks Jeff.
^ permalink raw reply
* [PATCH] xgmac: use bufsz not dma_buf_sz in rx_refill
From: Kyle McMartin @ 2013-08-29 20:11 UTC (permalink / raw)
To: rob.herring; +Cc: netdev
Noticed while debugging another issue that DMA debug turned up, looks
like commit ef468d23 missed a case when switching to bufsz instead of
priv->dma_buf_sz? (tbf, the whole handling of DMA buffers seems slightly
suspect since we're not tracking the size, but trusting the hardware
between map and unmap...)
Signed-off-by: Kyle McMartin <kyle@redhat.com>
--- a/drivers/net/ethernet/calxeda/xgmac.c
+++ b/drivers/net/ethernet/calxeda/xgmac.c
@@ -686,7 +686,7 @@ static void xgmac_rx_refill(struct xgmac_priv *priv)
priv->rx_skbuff[entry] = skb;
paddr = dma_map_single(priv->device, skb->data,
bufsz, DMA_FROM_DEVICE);
- desc_set_buf_addr(p, paddr, priv->dma_buf_sz);
+ desc_set_buf_addr(p, paddr, bufsz);
}
netdev_dbg(priv->dev, "rx ring: head %d, tail %d\n",
^ permalink raw reply
* Re: pull request (net): ipsec 2013-08-28
From: David Miller @ 2013-08-29 20:08 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1377687895-5780-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 28 Aug 2013 13:04:47 +0200
> This pull request fixes some issues that arise when 6in4 or 4in6 tunnels
> are used in combination with IPsec, all from Hannes Frederic Sowa and a
> null pointer dereference when queueing packets to the policy hold queue.
...
> Please pull or let me know if there are problems.
Pulled, thanks!
^ permalink raw reply
* Re: [PATCH v2] fec: Use NAPI_POLL_WEIGHT
From: David Miller @ 2013-08-29 20:00 UTC (permalink / raw)
To: festevam; +Cc: netdev, fabio.estevam
In-Reply-To: <1377635708-10159-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <festevam@gmail.com>
Date: Tue, 27 Aug 2013 17:35:08 -0300
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Instead of using a custom 'FEC_NAPI_WEIGHT', just use the generic
> 'NAPI_POLL_WEIGHT' definition instead.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] ipv4: sendto/hdrincl: don't use destination address found in header
From: David Miller @ 2013-08-29 19:59 UTC (permalink / raw)
To: chris.clark; +Cc: netdev
In-Reply-To: <alpine.DEB.2.02.1308271153040.2079@optio.utah.ind.alcatel.com>
From: Chris Clark <chris.clark@alcatel-lucent.com>
Date: Tue, 27 Aug 2013 12:02:15 -0600 (MDT)
>
> ipv4: raw_sendmsg: don't use header's destination address
>
> A sendto() regression was bisected and found to start with commit
> f8126f1d5136be1 (ipv4: Adjust semantics of rt->rt_gateway.)
>
> The problem is that it tries to ARP-lookup the constructed packet's
> destination address rather than the explicitly provided address.
>
> Fix this using FLOWI_FLAG_KNOWN_NH so that given nexthop is used.
>
> cf. commit 2ad5b9e4bd314fc685086b99e90e5de3bc59e26b
>
> Reported-by: Chris Clark <chris.clark@alcatel-lucent.com>
> Bisected-by: Chris Clark <chris.clark@alcatel-lucent.com>
> Tested-by: Chris Clark <chris.clark@alcatel-lucent.com>
> Suggested-by: Julian Anastasov <ja@ssi.bg>
> Signed-off-by: Chris Clark <chris.clark@alcatel-lucent.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] virtio-net: Set RXCSUM feature if GUEST_CSUM is available
From: David Miller @ 2013-08-29 19:57 UTC (permalink / raw)
To: thuth; +Cc: netdev, mst, virtualization
In-Reply-To: <1377616142-29590-1-git-send-email-thuth@linux.vnet.ibm.com>
From: Thomas Huth <thuth@linux.vnet.ibm.com>
Date: Tue, 27 Aug 2013 17:09:02 +0200
> If the VIRTIO_NET_F_GUEST_CSUM virtio feature is available, the guest
> does not have to calculate the checksums on all received packets. This
> is pretty much the same feature as RX checksum offloading on real
> network cards, so the virtio-net driver should report this by setting
> the NETIF_F_RXCSUM flag. When the user now runs "ethtool -k", he or she
> can see whether the virtio-net interface has to calculate RX checksums
> or not.
>
> Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Can one of the virtio_net folks please review this?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v3] net: sctp: sctp_verify_init: clean up mandatory checks and add comment
From: David Miller @ 2013-08-29 19:55 UTC (permalink / raw)
To: dborkman; +Cc: netdev, linux-sctp
In-Reply-To: <1377615232-11412-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Tue, 27 Aug 2013 16:53:52 +0200
> Add a comment related to RFC4960 explaning why we do not check for initial
> TSN, and while at it, remove yoda notation checks and clean up code from
> checks of mandatory conditions. That's probably just really minor, but makes
> reviewing easier.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next] tcp: TSO packets automatic sizing
From: David Miller @ 2013-08-29 19:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ncardwell, ycheng, vanj, therbert
In-Reply-To: <1377607592.8828.149.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 27 Aug 2013 05:46:32 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> After hearing many people over past years complaining against TSO being
> bursty or even buggy, we are proud to present automatic sizing of TSO
> packets.
>
> One part of the problem is that tcp_tso_should_defer() uses an heuristic
> relying on upcoming ACKS instead of a timer, but more generally, having
> big TSO packets makes little sense for low rates, as it tends to create
> micro bursts on the network, and general consensus is to reduce the
> buffering amount.
>
> This patch introduces a per socket sk_pacing_rate, that approximates
> the current sending rate, and allows us to size the TSO packets so
> that we try to send one packet every ms.
>
> This field could be set by other transports.
>
> Patch has no impact for high speed flows, where having large TSO packets
> makes sense to reach line rate.
>
> For other flows, this helps better packet scheduling and ACK clocking.
>
> This patch increases performance of TCP flows in lossy environments.
>
> A new sysctl (tcp_min_tso_segs) is added, to specify the
> minimal size of a TSO packet (default being 2).
>
> A follow-up patch will provide a new packet scheduler (FQ), using
> sk_pacing_rate as an input to perform optional per flow pacing.
>
> This explains why we chose to set sk_pacing_rate to twice the current
> rate, allowing 'slow start' ramp up.
>
> sk_pacing_rate = 2 * cwnd * mss / srtt
>
> v2: Neal Cardwell reported a suspect deferring of last two segments on
> initial write of 10 MSS, I had to change tcp_tso_should_defer() to take
> into account tp->xmit_size_goal_segs
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, please post a new copy of your accompanying packet scheduler.
Thanks.
^ permalink raw reply
* Re: [net-next v2 1/2] vxlan: Notify drivers for listening UDP port changes
From: Joseph Gasparakis @ 2013-08-29 19:55 UTC (permalink / raw)
To: Ben Hutchings
Cc: Jeff Kirsher, davem, Joseph Gasparakis, netdev, gospo, sassmann,
John Fastabend, Stephen Hemminger
In-Reply-To: <1377801778.5372.8.camel@bwh-desktop.uk.level5networks.com>
On Thu, 29 Aug 2013, Ben Hutchings wrote:
> On Thu, 2013-08-29 at 05:54 -0700, Jeff Kirsher wrote:
> > From: Joseph Gasparakis <joseph.gasparakis@intel.com>
> >
> > This patch adds two more ndo ops: ndo_add_rx_vxlan_port() and
> > ndo_del_rx_vxlan_port().
> [...]
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -948,6 +948,18 @@ struct netdev_phys_port_id {
> > * Called to get ID of physical port of this device. If driver does
> > * not implement this, it is assumed that the hw is not able to have
> > * multiple net devices on single physical port.
> > + *
> > + * int (*ndo_add_vxlan_port)(struct net_device *dev,
> > + * __u16 port);
> > + * Called by vxlan to notiy a driver about the UDP port that vxlan
> > + * is listnening to. It is called only when a new port starts listening.
> > + * The operation is protected by the vxlan_net->sock_lock.
> > + *
> > + * int (*ndo_del_vxlan_port)(struct net_device *dev,
> > + * __u16 port);
> > + * Called by vxlan to notify the driver about a UDP port of vxlan
> > + * that is not listening anymore. The operation is protected by
> > + * the vxlan_net->sock_lock.
> > */
> > struct net_device_ops {
> > int (*ndo_init)(struct net_device *dev);
> > @@ -1078,6 +1090,10 @@ struct net_device_ops {
> > bool new_carrier);
> > int (*ndo_get_phys_port_id)(struct net_device *dev,
> > struct netdev_phys_port_id *ppid);
> > + int (*ndo_add_vxlan_port)(struct net_device *dev,
> > + __u16 port);
> > + int (*ndo_del_vxlan_port)(struct net_device *dev,
> > + __u16 port);
> > };
> [...]
>
> I notice these are defined to return int, but the callers don't check
> the return value. Should they return void or do the callers need some
> error handling?
>
> Ben.
>
>
You are right Ben, these should be defined to return void. Will fix that
asap.
Joseph
^ permalink raw reply
* iproute2: add ability to filter neighbour discovery by protocol
From: Stephen Hemminger @ 2013-08-29 19:21 UTC (permalink / raw)
To: netdev
Useful to be able to monitor arp and IPv6 nd seperately.
Default is both.
---
ip/ipmonitor.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c
index 4895390..70f2a7a 100644
--- a/ip/ipmonitor.c
+++ b/ip/ipmonitor.c
@@ -36,7 +36,6 @@ static void usage(void)
exit(-1);
}
-
static int accept_msg(const struct sockaddr_nl *who,
struct nlmsghdr *n, void *arg)
{
@@ -88,6 +87,13 @@ static int accept_msg(const struct sockaddr_nl *who,
}
if (n->nlmsg_type == RTM_NEWNEIGH || n->nlmsg_type == RTM_DELNEIGH ||
n->nlmsg_type == RTM_GETNEIGH) {
+ if (preferred_family) {
+ struct ndmsg *r = NLMSG_DATA(n);
+
+ if (r->ndm_family != preferred_family)
+ return 0;
+ }
+
if (prefix_banner)
fprintf(fp, "[NEIGH]");
print_neigh(who, n, arg);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH net-next] pkt_sched: fq: Fair Queue packet scheduler
From: Matt Wilson @ 2013-08-29 19:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1377400082.8828.100.camel@edumazet-glaptop>
On Sat, Aug 24, 2013 at 08:08:02PM -0700, Eric Dumazet wrote:
[...]
> Attempts have been made to add TCP pacing in TCP stack, but this
> seems to add complex code to an already complex stack.
>
> TCP pacing is welcomed for flows having idle times, as the cwnd
> permits TCP stack to queue a possibly large number of packets.
>
> This removes the 'slow start after idle' choice, hitting badly
> large BDP flows.
>
> Nicely spaced packets : here interface is 10Gbit, but flow bottleneck is
> ~100Mbit
This is great. I just gave this a try in a real-world scenario where
TCP pacing (implemented in the TCP stack) has provided a significant
performance improvement.
# netperf -v 2 -H 10.162.184.110
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.162.184.110 (10.162.184.110) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.20 85.25
Alignment Offset Bytes Bytes Sends Bytes Recvs
Local Remote Local Remote Xfered Per Per
Send Recv Send Recv Send (avg) Recv (avg)
8 8 0 0 1.087e+08 16385.34 6635 14583.07 7455
Maximum
Segment
Size (bytes)
1424
# tc qdisc add dev eth0 root fq
# netperf -v 2 -H 10.162.184.110
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.162.184.110 (10.162.184.110) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.12 354.79
Alignment Offset Bytes Bytes Sends Bytes Recvs
Local Remote Local Remote Xfered Per Per
Send Recv Send Recv Send (avg) Recv (avg)
8 8 0 0 4.488e+08 16384.08 27394 15526.00 28908
Maximum
Segment
Size (bytes)
1424
Is there an iproute2 patch? I don't think I've seen one yet.
As far as this patch is concerned, I like what I see so far from
performance. Are there concerns about boundary crossing through
teaching the scheduler about things like the rate limit, special
handling of TCP retransmits, etc?
--msw
^ permalink raw reply
* Re: [PATCH] bridge: inherit slave devices needed_headroom
From: David Miller @ 2013-08-29 19:17 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, stephen, vyasevic, eric.dumazet
In-Reply-To: <1377601433-22353-1-git-send-email-f.fainelli@gmail.com>
From: "Florian Fainelli" <f.fainelli@gmail.com>
Date: Tue, 27 Aug 2013 12:03:53 +0100
> Some slave devices may have set a dev->needed_headroom value which is
> different than the default one, most likely in order to prepend a
> hardware descriptor in front of the Ethernet frame to send. Whenever a
> new slave is added to a bridge, ensure that we update the
> needed_headroom value accordingly to account for the slave
> needed_headroom value.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Since this is a performance optimization I've applied this to net-next.
Thanks!
^ permalink raw reply
* Re: [PATCH] tcp: don't apply tsoffset if rcv_tsecr is zero
From: David Miller @ 2013-08-29 19:12 UTC (permalink / raw)
To: avagin
Cc: netdev, gorcunov, linux-kernel, xemul, eric.dumazet, kuznet,
jmorris, yoshfuji, kaber
In-Reply-To: <1377591715-1742-1-git-send-email-avagin@openvz.org>
From: Andrey Vagin <avagin@openvz.org>
Date: Tue, 27 Aug 2013 12:21:55 +0400
> From: Andrew Vagin <avagin@openvz.org>
>
> The zero value means that tsecr is not valid, so it's a special case.
>
> tsoffset is used to customize tcp_time_stamp for one socket.
> tsoffset is usually zero, it's used when a socket was moved from one
> host to another host.
>
> Currently this issue affects logic of tcp_rcv_rtt_measure_ts. Due to
> incorrect value of rcv_tsecr, tcp_rcv_rtt_measure_ts sets rto to
> TCP_RTO_MAX.
>
> Reported-by: Cyrill Gorcunov <gorcunov@openvz.org>
> Signed-off-by: Andrey Vagin <avagin@openvz.org>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] tcp: initialize rcv_tstamp for restored sockets
From: David Miller @ 2013-08-29 19:12 UTC (permalink / raw)
To: avagin
Cc: netdev, gorcunov, linux-kernel, xemul, eric.dumazet, kuznet,
jmorris, yoshfuji, kaber
In-Reply-To: <1377591640-1660-1-git-send-email-avagin@openvz.org>
From: Andrey Vagin <avagin@openvz.org>
Date: Tue, 27 Aug 2013 12:20:40 +0400
> From: Andrew Vagin <avagin@openvz.org>
>
> u32 rcv_tstamp; /* timestamp of last received ACK */
>
> Its value used in tcp_retransmit_timer, which closes socket
> if the last ack was received more then TCP_RTO_MAX ago.
>
> Currently rcv_tstamp is initialized to zero and if tcp_retransmit_timer
> is called before receiving a first ack, the connection is closed.
>
> This patch initializes rcv_tstamp to a timestamp, when a socket was
> restored.
>
> Reported-by: Cyrill Gorcunov <gorcunov@openvz.org>
> Signed-off-by: Andrey Vagin <avagin@openvz.org>
Applied and queued up for -stable.
^ 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