* Re: [PATCH net-next v10 10/11] vxlan: respect scope_id for ll addr
From: David Stevens @ 2013-08-29 21:20 UTC (permalink / raw)
To: Cong Wang; +Cc: Cong Wang, David S. Miller, netdev, netdev-owner
In-Reply-To: <1377667379-2315-11-git-send-email-amwang@redhat.com>
netdev-owner@vger.kernel.org wrote on 08/28/2013 01:22:58 AM:
> From: Cong Wang <amwang@redhat.com>
> As pointed out by David, we should take care of scope id for ll
> addr, and use it for route lookup.
It is an error to have a zero scope_id for an LL addr, but
this code is not correct, because it only honors scope_id for
LL addrs. Multicast addresses also require scope_id be set.
This shouldn't be in the transmit path. The netlink code
that sets it should require it be nonzero for LL addrs and multicast
addrs when it is set, and the transmit path should *always* use scope_id,
whether for an lladdr or not, whether scope_id is zero or not.
I'm away this week and won't be able to review these in
detail until next week, but wanted to get that comment in.
+-DLS
^ permalink raw reply
* pull-request: can-next 2013-08-29
From: Marc Kleine-Budde @ 2013-08-29 21:13 UTC (permalink / raw)
To: Linux Netdev List
Cc: linux-can@vger.kernel.org, David Miller, kernel@pengutronix.de
[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]
Hello David,
this is a pull request for net-next. There are two patches from Gerhard
Sittig, which improves the clock handling on mpc5121. Oliver Hartkopp
provides a patch that adds a per rule limitation of frame hops.
regards,
Marc
---
The following changes since commit 7ec06da81d2b98859b558d8d551a0c4e3d9516a3:
net: packet: document available fanout policies (2013-08-29 16:43:29 -0400)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can-next.git for-davem
for you to fetch changes up to 391ac1282dd7ff1cb8245cccc5262e8e4173edc4:
can: gw: add a per rule limitation of frame hops (2013-08-29 22:58:24 +0200)
----------------------------------------------------------------
Gerhard Sittig (2):
can: mscan: add a comment on reg to idx mapping
can: mscan: improve clock API use
Oliver Hartkopp (1):
can: gw: add a per rule limitation of frame hops
drivers/net/can/mscan/mpc5xxx_can.c | 23 ++++++++++++++++-------
drivers/net/can/mscan/mscan.c | 25 ++++++++++++++++++++++++-
drivers/net/can/mscan/mscan.h | 3 +++
include/uapi/linux/can/gw.h | 9 ++++++++-
net/can/gw.c | 35 +++++++++++++++++++++++++++++++----
5 files changed, 82 insertions(+), 13 deletions(-)
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [ethtool 3/3] ethtool: add ixgbevf support for register dump
From: Ben Hutchings @ 2013-08-29 20:57 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: Jacob Keller, netdev, gospo, sassmann
In-Reply-To: <1377648529-8297-3-git-send-email-jeffrey.t.kirsher@intel.com>
On Tue, 2013-08-27 at 17:08 -0700, Jeff Kirsher wrote:
> From: Jacob Keller <jacob.e.keller@intel.com>
>
> This patch adds support for the ixgbevf driver, which previously was printing
> out as hex dump, and in the driver via printk. This patch corrects the
> implementation to have a new ixgbevf_reg_dump function that will format the
> register output in a more human readable format.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Tested-by: Stephen Ko <stephen.s.ko@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, but:
[...]
> --- /dev/null
> +++ b/ixgbevf.c
> @@ -0,0 +1,180 @@
> +/* Copyright (c) 2007 Intel Corporation */
[...]
I'm not sure whether to believe this date...
Ben.
--
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
* Re: [PATCH 2/2] realtek: update devices to 3.11
From: Ben Hutchings @ 2013-08-29 20:52 UTC (permalink / raw)
To: Peter Wu; +Cc: netdev, Francois Romieu
In-Reply-To: <1376429119-31380-3-git-send-email-lekensteyn@gmail.com>
On Tue, 2013-08-13 at 23:25 +0200, Peter Wu wrote:
> RTL8168_8111Bb/RTL8168_8111Bef is like RTL8111B/RTL8168B, RTL8100E and RTL8101E
> (datasheet revision 1.0 from 26 January 2006). Assume that RTL8101e is also
> similar (I may be very wrong at that though...).
>
> Note that the scanning heuristics is the same as the r8169 module: newer devices
> with stronger masks come before the others. Perhaps the older 8139 cards should
> be appended to the list, after all r8169 chips.
>
> Signed-off-by: Peter Wu <lekensteyn@gmail.com>
[...]
Applied, thanks.
Ben.
--
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
* Re: [PATCH 1/2] realtek: convert to per-chip mask
From: Ben Hutchings @ 2013-08-29 20:51 UTC (permalink / raw)
To: Peter Wu; +Cc: netdev, Francois Romieu
In-Reply-To: <1376429119-31380-2-git-send-email-lekensteyn@gmail.com>
On Tue, 2013-08-13 at 23:25 +0200, Peter Wu wrote:
> The previous HW_REVID macro did not make identifiers more readable
> (compared to hex values like 0x12345678) and only allowed for one static
> mask. To make it easier to update the chips list, let's use similar
> structures as r8169 and remove HW_REVID.
>
> Names are removed and separated from the table and separated because the
> mac_version does not have to be unique.
>
> While at it, change "RTL-xxxx" to "RTLxxxx" to match the names of
> Realtek and r8169 driver. Besides that, the only output change is when
> a chip is not recognized in which case "TxConfig" is now mentioned
> instead of "mask". Since the mask can be anything, the displayed word is
> not masked either.
>
> Signed-off-by: Peter Wu <lekensteyn@gmail.com>
[...]
Applied, thanks.
Ben.
--
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
* Re: [ethtool 1/3] ethtool: fix ixgbe 82598EB only registers
From: Ben Hutchings @ 2013-08-29 20:51 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: Jacob Keller, netdev, gospo, sassmann
In-Reply-To: <1377648529-8297-1-git-send-email-jeffrey.t.kirsher@intel.com>
On Tue, 2013-08-27 at 17:08 -0700, Jeff Kirsher wrote:
> From: Jacob Keller <jacob.e.keller@intel.com>
>
> This patch fixes ixgbe_reg_dump to only display registers specific to the
> 82598EB part, as these registers display 0xDEADBEEF otherwise, and clutter up
> the register dump.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> ixgbe.c | 144 +++++++++++++++++++++++++++++++++-------------------------------
> 1 file changed, 75 insertions(+), 69 deletions(-)
>
> diff --git a/ixgbe.c b/ixgbe.c
> index 9b005f2..89cb6be 100644
> --- a/ixgbe.c
> +++ b/ixgbe.c
[...]
> - fprintf(stdout,
> - "0x02F20: RDPROBE (Rx Probe Mode Status) 0x%08X\n",
> - regs_buff[1085]);
[...]
It looks like this removal really belongs to the next patch, which adds
it back with the mac_type < ixgbe_mac_X540 condition.
Ben.
--
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
* Re: VLAN filtering/VLAN aware bridge problems
From: Vlad Yasevich @ 2013-08-29 20:45 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: David Miller, Linux Netdev List
In-Reply-To: <521F4393.1020907@profihost.ag>
On 08/29/2013 08:50 AM, Stefan Priebe - Profihost AG wrote:
> Hello,
>
> currently i'm running vanilla 3.8.8 kernel with some tap devices using
> VLANs on top of a bridge on top of a bond.
>
> This works fine and everything is great.
>
> Now i started to test 3.10.9 and all my VLANs stopped working no matter
> i disable or enable CONFIG_BRIDGE_VLAN_FILTERING.
Just enabling config option doesn't turn on the filtering behavior.
>
> The packets never reach the TAP device.
>
> Here is an output of ip a l (vlan 3021):
Can you provide output of brctl show?
>
> ip a l
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,PROMISC,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
> mq master bond0 state UP qlen 1000
> link/ether 00:25:90:84:de:a8 brd ff:ff:ff:ff:ff:ff
> 3: eth4: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq
> master bond5 state UP qlen 10000
> link/ether 90:e2:ba:33:45:0c brd ff:ff:ff:ff:ff:ff
> 4: eth1: <BROADCAST,MULTICAST,PROMISC,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
> mq master bond0 state UP qlen 1000
> link/ether 00:25:90:84:de:a8 brd ff:ff:ff:ff:ff:ff
> 5: eth2: <BROADCAST,MULTICAST,PROMISC,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
> mq master bond1 state UP qlen 1000
> link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
> 6: eth5: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq
> master bond5 state UP qlen 10000
> link/ether 90:e2:ba:33:45:0c brd ff:ff:ff:ff:ff:ff
> 7: eth3: <BROADCAST,MULTICAST,PROMISC,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
> mq master bond1 state UP qlen 1000
> link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
> 8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc
> noqueue master vmbr0 state UP
> link/ether 00:25:90:84:de:a8 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::225:90ff:fe84:dea8/64 scope link
> valid_lft forever preferred_lft forever
> 9: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc
> noqueue master vmbr1 state UP
> link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
> inet6 fe80::225:90ff:fe84:deaa/64 scope link
> valid_lft forever preferred_lft forever
> 10: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP
> link/ether 00:25:90:84:de:a8 brd ff:ff:ff:ff:ff:ff
> inet 178.250.9.30/25 brd 178.250.9.127 scope global vmbr0
> valid_lft forever preferred_lft forever
> inet6 fe80::225:90ff:fe84:dea8/64 scope link
> valid_lft forever preferred_lft forever
> 11: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP
> link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
> inet6 fe80::225:90ff:fe84:deaa/64 scope link
> valid_lft forever preferred_lft forever
> 12: bond5: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc
> noqueue state UP
> link/ether 90:e2:ba:33:45:0c brd ff:ff:ff:ff:ff:ff
> inet 10.255.0.30/24 brd 10.255.0.255 scope global bond5
> valid_lft forever preferred_lft forever
> inet6 fe80::92e2:baff:fe33:450c/64 scope link
> valid_lft forever preferred_lft forever
> 15: vmbr1.3020@vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> noqueue master vmbr1v3020 state UP
> link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
> inet6 fe80::225:90ff:fe84:deaa/64 scope link
> valid_lft forever preferred_lft forever
> 16: vmbr1v3020: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP
> link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
> inet6 fe80::f036:92ff:fe40:7224/64 scope link
> valid_lft forever preferred_lft forever
> 19: tap320i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
> htb master vmbr0 state UNKNOWN qlen 500
> link/ether fe:fa:14:cc:75:b2 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::fcfa:14ff:fecc:75b2/64 scope link
> valid_lft forever preferred_lft forever
> 20: tap320i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
> htb master vmbr1v3021 state UNKNOWN qlen 500
> link/ether 8a:f3:9b:47:c7:88 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::88f3:9bff:fe47:c788/64 scope link
> valid_lft forever preferred_lft forever
> 21: vmbr1.3021@vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> noqueue master vmbr1v3021 state UP
> link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
> inet6 fe80::225:90ff:fe84:deaa/64 scope link
> valid_lft forever preferred_lft forever
> 22: vmbr1v3021: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP
> link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
> inet6 fe80::9868:5eff:fe9d:bf56/64 scope link
> valid_lft forever preferred_lft forever
>
I can only guess that the configuration based on the above data. Can
you give a diagram of the config.
On the off chance that you are actually trying to configure vlan
filtering, can you give this patch a try (net-2.6 tree):
Author: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date: Tue Aug 20 17:10:18 2013 +0900
bridge: Use the correct bit length for bitmap functions in the VLAN
code
I don't think it made it to stable yet.
Thanks
-vlad
> Greets,
> Stefan
>
^ permalink raw reply
* Re: [PATCH net-next 0/3] pf_packet updates
From: David Miller @ 2013-08-29 20:43 UTC (permalink / raw)
To: dborkman; +Cc: netdev, amwang
In-Reply-To: <521EE81E.7030800@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Thu, 29 Aug 2013 08:20:14 +0200
> On 08/29/2013 07:39 AM, David Miller wrote:
>> From: Daniel Borkmann <dborkman@redhat.com>
>> Date: Wed, 28 Aug 2013 22:13:08 +0200
>>
>>> Daniel Borkmann (3):
>>> net: packet: add random fanout scheduler
>>> net: packet: use reciprocal_divide in fanout_demux_hash
>>> net: packet: document available fanout policies
>>
>> Please add the missing reciprocal_divide.h include to the second
>> patch, as per Eric Dumazet's feedback, and resubmit this series.
>
> That is already the case in the first patch of the series. It adds:
>
> ...
> +#include <linux/reciprocal_div.h>
Series applied, thanks Daniel.
^ permalink raw reply
* Re: [PATCH] xgmac: use bufsz not dma_buf_sz in rx_refill
From: David Miller @ 2013-08-29 20:38 UTC (permalink / raw)
To: kmcmarti; +Cc: rob.herring, netdev
In-Reply-To: <20130829203523.GL8764@redacted.bos.redhat.com>
From: Kyle McMartin <kmcmarti@redhat.com>
Date: Thu, 29 Aug 2013 16:35:23 -0400
> 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.
If Rob had resubmitted his series in a timely manner this wouldn't
have happened.
I reverted.
^ permalink raw reply
* Re: [PATCH] xgmac: use bufsz not dma_buf_sz in rx_refill
From: David Miller @ 2013-08-29 20:38 UTC (permalink / raw)
To: rob.herring; +Cc: kyle, netdev
In-Reply-To: <521FADFE.7040908@calxeda.com>
From: Rob Herring <rob.herring@calxeda.com>
Date: Thu, 29 Aug 2013 15:24:30 -0500
> 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
Which need to be resubmitted with feedback intergrated.
I knew your series existed, but Kyle submitted a fix in the correct
format meanwhile so I applied it.
^ permalink raw reply
* 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
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