* Re: [net-next.git 0/6 (V5)] stmmac: remove dead code for STMMAC_TIMER and add new mitigation schema
From: David Miller @ 2012-11-26 22:23 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, bhutchings
In-Reply-To: <1353921046-5121-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Mon, 26 Nov 2012 10:10:40 +0100
> These patch series remove the STMMAC_TIMER option no longer updated
> and never used and add a new mitigation schema.
> Having removed the Timer opt, this has made the driver slim.
> On top of this work, it has been easier to introduce the new
> mitigation schema based on HW RX-watchdog (available in new cores).
> In fact, 3.50 and newer cores have an HW RX-Watchdog that can be used for
> mitigating the Rx-interrupts and first results look promising.
All applied to net-next
^ permalink raw reply
* Re: [PATCH net-next 0/2] tun: trivial fixes.
From: David Miller @ 2012-11-26 22:22 UTC (permalink / raw)
To: ramirose; +Cc: maxk, netdev
In-Reply-To: <1353917261-2974-1-git-send-email-ramirose@gmail.com>
From: Rami Rosen <ramirose@gmail.com>
Date: Mon, 26 Nov 2012 10:07:39 +0200
> These two patches contain trivial fixes to the tun driver.
> First patch fixes 4 typos.
> Second patch puts the correct method name in a debug message in tun_do_read().
>
> Rami Rosen (2):
> [PATCH net-next 1/2] vtun: fix typos.
> [PATCH net-next 2/2] tun: put correct method name in a debug message.
All applied to net-next
^ permalink raw reply
* Re: [PATCH v2] atm: br2684: Fix excessive queue bloat
From: David Miller @ 2012-11-26 22:16 UTC (permalink / raw)
To: dwmw2; +Cc: netdev, blogic, dave.taht, chas
In-Reply-To: <1353881212.26346.303.camel@shinybook.infradead.org>
Applied, thanks a lot.
^ permalink raw reply
* Re: pull-request: can 2012-11-26
From: David Miller @ 2012-11-26 22:16 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <1353966430-12601-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 26 Nov 2012 22:47:08 +0100
> two late fixes for v3.7 from Oliver Hartkopp, he found and fixed a problem in
> the peak usb driver, a hardware timestamp is assigned wrong. In the second
> patch he fixed a problem in the broadcast manager, in case of a timeout the
> rx_ifindex is not set properly.
Pulled, but I cannot guarentee these will make it into 3.7 as
this is very late and I am also travelling.
Worst case is they end up in net-next and you can submit them
to -stable if you wish.
^ permalink raw reply
* Re: [PATCH net-next] dsa: Hide core config options; make drivers select what they need
From: David Miller @ 2012-11-26 22:11 UTC (permalink / raw)
To: rdunlap; +Cc: bhutchings, netdev, viresh.kumar
In-Reply-To: <50B3C8B0.5000308@infradead.org>
From: Randy Dunlap <rdunlap@infradead.org>
Date: Mon, 26 Nov 2012 11:53:20 -0800
> On 11/26/2012 11:16 AM, Ben Hutchings wrote:
>
>> Commit 82167cb8c6b2f8166d5c7532e5ef4b5e0cc46a72 ('net: dsa/slave: Fix
>> compilation warnings') fixed one possible invalid configuration
>> (NET_DSA enabled with no trailer formats) but added others: drivers
>> can select NET_DSA without its dependencies being met.
>>
>> It's not very useful to make either the DSA core or the tagging
>> formats manually selectable without a driver to use them, so:
>>
>> 1. Define a hidden HAVE_NET_DSA option and move the dependencies of
>> NET_DSA to that. While we're at it, drop the deprecated
>> EXPERIMENTAL dependency.
>> 2. Make NET_DSA and the drivers dependent on HAVE_NET_DSA.
>> 3. Hide the tagging format options again.
>> 4. Make drivers select both NET_DSA and the appropriate tagging format
>> option.
>>
>> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
>
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
Applied, thanks everyone.
^ permalink raw reply
* [PATCH 1/2] can: peak_usb: fix hwtstamp assignment
From: Marc Kleine-Budde @ 2012-11-26 21:47 UTC (permalink / raw)
To: netdev; +Cc: linux-can, Oliver Hartkopp, linux-stable, Marc Kleine-Budde
In-Reply-To: <1353966430-12601-1-git-send-email-mkl@pengutronix.de>
From: Oliver Hartkopp <socketcan@hartkopp.net>
The skb->tstamp is set to the hardware timestamp when available in the USB
urb message. This leads to user visible timestamps which contain the 'uptime'
of the USB adapter - and not the usual system generated timestamp.
Fix this wrong assignment by applying the available hardware timestamp to the
skb_shared_hwtstamps data structure - which is intended for this purpose.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/peak_usb/pcan_usb.c | 8 ++++++--
drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 8 ++++++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb.c b/drivers/net/can/usb/peak_usb/pcan_usb.c
index 86f26a1..25723d8 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb.c
@@ -519,8 +519,10 @@ static int pcan_usb_decode_error(struct pcan_usb_msg_context *mc, u8 n,
mc->pdev->dev.can.state = new_state;
if (status_len & PCAN_USB_STATUSLEN_TIMESTAMP) {
+ struct skb_shared_hwtstamps *hwts = skb_hwtstamps(skb);
+
peak_usb_get_ts_tv(&mc->pdev->time_ref, mc->ts16, &tv);
- skb->tstamp = timeval_to_ktime(tv);
+ hwts->hwtstamp = timeval_to_ktime(tv);
}
netif_rx(skb);
@@ -605,6 +607,7 @@ static int pcan_usb_decode_data(struct pcan_usb_msg_context *mc, u8 status_len)
struct sk_buff *skb;
struct can_frame *cf;
struct timeval tv;
+ struct skb_shared_hwtstamps *hwts;
skb = alloc_can_skb(mc->netdev, &cf);
if (!skb)
@@ -652,7 +655,8 @@ static int pcan_usb_decode_data(struct pcan_usb_msg_context *mc, u8 status_len)
/* convert timestamp into kernel time */
peak_usb_get_ts_tv(&mc->pdev->time_ref, mc->ts16, &tv);
- skb->tstamp = timeval_to_ktime(tv);
+ hwts = skb_hwtstamps(skb);
+ hwts->hwtstamp = timeval_to_ktime(tv);
/* push the skb */
netif_rx(skb);
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
index e1626d9..30d79bf 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
@@ -532,6 +532,7 @@ static int pcan_usb_pro_handle_canmsg(struct pcan_usb_pro_interface *usb_if,
struct can_frame *can_frame;
struct sk_buff *skb;
struct timeval tv;
+ struct skb_shared_hwtstamps *hwts;
skb = alloc_can_skb(netdev, &can_frame);
if (!skb)
@@ -549,7 +550,8 @@ static int pcan_usb_pro_handle_canmsg(struct pcan_usb_pro_interface *usb_if,
memcpy(can_frame->data, rx->data, can_frame->can_dlc);
peak_usb_get_ts_tv(&usb_if->time_ref, le32_to_cpu(rx->ts32), &tv);
- skb->tstamp = timeval_to_ktime(tv);
+ hwts = skb_hwtstamps(skb);
+ hwts->hwtstamp = timeval_to_ktime(tv);
netif_rx(skb);
netdev->stats.rx_packets++;
@@ -570,6 +572,7 @@ static int pcan_usb_pro_handle_error(struct pcan_usb_pro_interface *usb_if,
u8 err_mask = 0;
struct sk_buff *skb;
struct timeval tv;
+ struct skb_shared_hwtstamps *hwts;
/* nothing should be sent while in BUS_OFF state */
if (dev->can.state == CAN_STATE_BUS_OFF)
@@ -664,7 +667,8 @@ static int pcan_usb_pro_handle_error(struct pcan_usb_pro_interface *usb_if,
dev->can.state = new_state;
peak_usb_get_ts_tv(&usb_if->time_ref, le32_to_cpu(er->ts32), &tv);
- skb->tstamp = timeval_to_ktime(tv);
+ hwts = skb_hwtstamps(skb);
+ hwts->hwtstamp = timeval_to_ktime(tv);
netif_rx(skb);
netdev->stats.rx_packets++;
netdev->stats.rx_bytes += can_frame->can_dlc;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] can: bcm: initialize ifindex for timeouts without previous frame reception
From: Marc Kleine-Budde @ 2012-11-26 21:47 UTC (permalink / raw)
To: netdev; +Cc: linux-can, Oliver Hartkopp, linux-stable, Marc Kleine-Budde
In-Reply-To: <1353966430-12601-1-git-send-email-mkl@pengutronix.de>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Set in the rx_ifindex to pass the correct interface index in the case of a
message timeout detection. Usually the rx_ifindex value is set at receive
time. But when no CAN frame has been received the RX_TIMEOUT notification
did not contain a valid value.
Cc: linux-stable <stable@vger.kernel.org>
Reported-by: Andre Naujoks <nautsch2@googlemail.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
net/can/bcm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 6f74758..969b7cd 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -1084,6 +1084,9 @@ static int bcm_rx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
op->sk = sk;
op->ifindex = ifindex;
+ /* ifindex for timeout events w/o previous frame reception */
+ op->rx_ifindex = ifindex;
+
/* initialize uninitialized (kzalloc) structure */
hrtimer_init(&op->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
op->timer.function = bcm_rx_timeout_handler;
--
1.7.10.4
^ permalink raw reply related
* pull-request: can 2012-11-26
From: Marc Kleine-Budde @ 2012-11-26 21:47 UTC (permalink / raw)
To: netdev; +Cc: linux-can
Hello David,
two late fixes for v3.7 from Oliver Hartkopp, he found and fixed a problem in
the peak usb driver, a hardware timestamp is assigned wrong. In the second
patch he fixed a problem in the broadcast manager, in case of a timeout the
rx_ifindex is not set properly.
regards, Marc
---
The following changes since commit 194d9831f0419b5125dc94ec0ece4434d8ef74f0:
Merge tag 'sound-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound (2012-11-24 08:32:11 -1000)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can.git fixes-for-3.7
for you to fetch changes up to 81b401100c01d2357031e874689f89bd788d13cd:
can: bcm: initialize ifindex for timeouts without previous frame reception (2012-11-26 22:33:59 +0100)
----------------------------------------------------------------
Oliver Hartkopp (2):
can: peak_usb: fix hwtstamp assignment
can: bcm: initialize ifindex for timeouts without previous frame reception
drivers/net/can/usb/peak_usb/pcan_usb.c | 8 ++++++--
drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 8 ++++++--
net/can/bcm.c | 3 +++
3 files changed, 15 insertions(+), 4 deletions(-)
^ permalink raw reply
* re: smsc95xx: detect chip revision specific features
From: Dan Carpenter @ 2012-11-26 20:47 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev
Hello Steve Glendinning,
The patch 9ebca5071c86: "smsc95xx: detect chip revision specific
features" from Nov 22, 2012, leads to the following warning:
drivers/net/usb/smsc95xx.c:1349 smsc95xx_suspend()
error: buffer overflow 'filter_mask' 8 <= 31
drivers/net/usb/smsc95xx.c
1283 if (pdata->wolopts & (WAKE_BCAST | WAKE_MCAST | WAKE_ARP | WAKE_UCAST)) {
1284 u32 *filter_mask = kzalloc(32, GFP_KERNEL);
^^
We allocate 8 unsigned 32 bit values. I think this is the mistake here
actually. It is a typo and should say:
u32 *filter_mask = kzalloc(sizeof(u32) * 32, GFP_KERNEL);
If 8 elements was the intent then that's nasty.
1285 u32 command[2];
1286 u32 offset[2];
1287 u32 crc[4];
1288 int wuff_filter_count =
1289 (pdata->features & FEATURE_8_WAKEUP_FILTERS) ?
1290 LAN9500A_WUFF_NUM : LAN9500_WUFF_NUM;
LAN9500A_WUFF_NUM is 8. LAN9500_WUFF_NUM is 4.
1291 int i, filter = 0;
1292
[snip]
1348 for (i = 0; i < (wuff_filter_count * 4); i++) {
^^^^^^^^^^^^^^^^^^^^^
We are either counting to 15 or 31, and both are more that 8.
1349 ret = smsc95xx_write_reg_nopm(dev, WUFF, filter_mask[i]);
^^^^^^^^^^^^^^
So we're going past the end of the 8 element array.
1350 if (ret < 0)
1351 kfree(filter_mask);
1352 check_warn_return(ret, "Error writing WUFF\n");
1353 }
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH RFC] [INET]: Get cirtical word in first 64bit of cache line
From: Ben Hutchings @ 2012-11-26 20:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: ling.ma.program, linux-kernel, netdev
In-Reply-To: <1353912241.30446.1257.camel@edumazet-glaptop>
On Sun, 2012-11-25 at 22:44 -0800, Eric Dumazet wrote:
> On Mon, 2012-11-26 at 11:29 +0800, ling.ma.program@gmail.com wrote:
> > From: Ma Ling <ling.ma.program@gmail.com>
> >
> > In order to reduce memory latency when last level cache miss occurs,
> > modern CPUs i.e. x86 and arm introduced Critical Word First(CWF) or
> > Early Restart(ER) to get data ASAP. For CWF if critical word is first member
> > in cache line, memory feed CPU with critical word, then fill others
> > data in cache line one by one, otherwise after critical word it must
> > cost more cycle to fill the remaining cache line. For Early First CPU will
> > restart until critical word in cache line reaches.
> >
> > Hash value is critical word, so in this patch we place it as first member
> > in cache line(sock address is cache-line aligned), and it is also good for
> > Early Restart platform as well .
> >
> > Thanks
> > Ling
>
> networking patches should be sent to netdev.
>
> (I understand this patch is more a generic one, but at least CC netdev)
>
> You give no performance numbers for this change...
>
> I never heard of this CWF/ER, where are the official Intel documents
> about this, and what models really benefit from it ?
[...]
CWF is a standard feature of SDRAM. Ulrich Drepper's series of articles
on memory covers this in part 2 <http://lwn.net/Articles/252125/>
section 3.5.2. As for whether it's slower to start fetching from the
middle, that may depend on the memory controller and memory type that
are used. Drepper's benchmark showed only a small penalty (<1%) for
fetching from the middle, though he didn't say anything particular about
the hardware configuration.
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 net-next] dsa: Hide core config options; make drivers select what they need
From: Randy Dunlap @ 2012-11-26 19:53 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, Viresh Kumar
In-Reply-To: <1353957370.2717.3.camel@bwh-desktop.uk.solarflarecom.com>
On 11/26/2012 11:16 AM, Ben Hutchings wrote:
> Commit 82167cb8c6b2f8166d5c7532e5ef4b5e0cc46a72 ('net: dsa/slave: Fix
> compilation warnings') fixed one possible invalid configuration
> (NET_DSA enabled with no trailer formats) but added others: drivers
> can select NET_DSA without its dependencies being met.
>
> It's not very useful to make either the DSA core or the tagging
> formats manually selectable without a driver to use them, so:
>
> 1. Define a hidden HAVE_NET_DSA option and move the dependencies of
> NET_DSA to that. While we're at it, drop the deprecated
> EXPERIMENTAL dependency.
> 2. Make NET_DSA and the drivers dependent on HAVE_NET_DSA.
> 3. Hide the tagging format options again.
> 4. Make drivers select both NET_DSA and the appropriate tagging format
> option.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> drivers/net/dsa/Kconfig | 4 ++++
> net/dsa/Kconfig | 30 +++++++++++++-----------------
> 2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
> index 96eae22..b8fe808 100644
> --- a/drivers/net/dsa/Kconfig
> +++ b/drivers/net/dsa/Kconfig
> @@ -1,4 +1,5 @@
> menu "Distributed Switch Architecture drivers"
> + depends on HAVE_NET_DSA
>
> config NET_DSA_MV88E6XXX
> tristate
> @@ -6,6 +7,7 @@ config NET_DSA_MV88E6XXX
>
> config NET_DSA_MV88E6060
> tristate "Marvell 88E6060 ethernet switch chip support"
> + select NET_DSA
> select NET_DSA_TAG_TRAILER
> ---help---
> This enables support for the Marvell 88E6060 ethernet switch
> @@ -17,6 +19,7 @@ config NET_DSA_MV88E6XXX_NEED_PPU
>
> config NET_DSA_MV88E6131
> tristate "Marvell 88E6085/6095/6095F/6131 ethernet switch chip support"
> + select NET_DSA
> select NET_DSA_MV88E6XXX
> select NET_DSA_MV88E6XXX_NEED_PPU
> select NET_DSA_TAG_DSA
> @@ -26,6 +29,7 @@ config NET_DSA_MV88E6131
>
> config NET_DSA_MV88E6123_61_65
> tristate "Marvell 88E6123/6161/6165 ethernet switch chip support"
> + select NET_DSA
> select NET_DSA_MV88E6XXX
> select NET_DSA_TAG_EDSA
> ---help---
> diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
> index 0f5dc34..f5eede1 100644
> --- a/net/dsa/Kconfig
> +++ b/net/dsa/Kconfig
> @@ -1,28 +1,24 @@
> +config HAVE_NET_DSA
> + def_bool y
> + depends on NETDEVICES && !S390
> +
> +# Drivers must select NET_DSA and the appropriate tagging format
> +
> config NET_DSA
> tristate
> - default n
> - depends on EXPERIMENTAL && NETDEVICES && !S390
> + depends on HAVE_NET_DSA
> select PHYLIB
> - ---help---
> - This allows you to use hardware switch chips that use
> - the Distributed Switch Architecture.
>
> -
> -menu "Distributed Switch Architecture support"
> +if NET_DSA
>
> # tagging formats
> config NET_DSA_TAG_DSA
> - bool "Original DSA packet tagging format"
> - select NET_DSA
> - default n
> + bool
>
> config NET_DSA_TAG_EDSA
> - bool "Ethertype DSA packet tagging format"
> - select NET_DSA
> - default n
> + bool
>
> config NET_DSA_TAG_TRAILER
> - bool "Trailer DSA packet tagging format"
> - select NET_DSA
> - default n
> -endmenu
> + bool
> +
> +endif
--
~Randy
^ permalink raw reply
* [PATCH net-next] dsa: Hide core config options; make drivers select what they need
From: Ben Hutchings @ 2012-11-26 19:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Viresh Kumar, Randy Dunlap
Commit 82167cb8c6b2f8166d5c7532e5ef4b5e0cc46a72 ('net: dsa/slave: Fix
compilation warnings') fixed one possible invalid configuration
(NET_DSA enabled with no trailer formats) but added others: drivers
can select NET_DSA without its dependencies being met.
It's not very useful to make either the DSA core or the tagging
formats manually selectable without a driver to use them, so:
1. Define a hidden HAVE_NET_DSA option and move the dependencies of
NET_DSA to that. While we're at it, drop the deprecated
EXPERIMENTAL dependency.
2. Make NET_DSA and the drivers dependent on HAVE_NET_DSA.
3. Hide the tagging format options again.
4. Make drivers select both NET_DSA and the appropriate tagging format
option.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/dsa/Kconfig | 4 ++++
net/dsa/Kconfig | 30 +++++++++++++-----------------
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 96eae22..b8fe808 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -1,4 +1,5 @@
menu "Distributed Switch Architecture drivers"
+ depends on HAVE_NET_DSA
config NET_DSA_MV88E6XXX
tristate
@@ -6,6 +7,7 @@ config NET_DSA_MV88E6XXX
config NET_DSA_MV88E6060
tristate "Marvell 88E6060 ethernet switch chip support"
+ select NET_DSA
select NET_DSA_TAG_TRAILER
---help---
This enables support for the Marvell 88E6060 ethernet switch
@@ -17,6 +19,7 @@ config NET_DSA_MV88E6XXX_NEED_PPU
config NET_DSA_MV88E6131
tristate "Marvell 88E6085/6095/6095F/6131 ethernet switch chip support"
+ select NET_DSA
select NET_DSA_MV88E6XXX
select NET_DSA_MV88E6XXX_NEED_PPU
select NET_DSA_TAG_DSA
@@ -26,6 +29,7 @@ config NET_DSA_MV88E6131
config NET_DSA_MV88E6123_61_65
tristate "Marvell 88E6123/6161/6165 ethernet switch chip support"
+ select NET_DSA
select NET_DSA_MV88E6XXX
select NET_DSA_TAG_EDSA
---help---
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index 0f5dc34..f5eede1 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -1,28 +1,24 @@
+config HAVE_NET_DSA
+ def_bool y
+ depends on NETDEVICES && !S390
+
+# Drivers must select NET_DSA and the appropriate tagging format
+
config NET_DSA
tristate
- default n
- depends on EXPERIMENTAL && NETDEVICES && !S390
+ depends on HAVE_NET_DSA
select PHYLIB
- ---help---
- This allows you to use hardware switch chips that use
- the Distributed Switch Architecture.
-
-menu "Distributed Switch Architecture support"
+if NET_DSA
# tagging formats
config NET_DSA_TAG_DSA
- bool "Original DSA packet tagging format"
- select NET_DSA
- default n
+ bool
config NET_DSA_TAG_EDSA
- bool "Ethertype DSA packet tagging format"
- select NET_DSA
- default n
+ bool
config NET_DSA_TAG_TRAILER
- bool "Trailer DSA packet tagging format"
- select NET_DSA
- default n
-endmenu
+ bool
+
+endif
--
1.7.7.6
--
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 net-next:master 20/25] net/dsa: make DSA tagging depend on NETDEVICES and !S390
From: Ben Hutchings @ 2012-11-26 18:57 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Viresh Kumar, kbuild test robot, davem, netdev
In-Reply-To: <50B3B9F6.5060509@infradead.org>
On Mon, 2012-11-26 at 10:50 -0800, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix kconfig dependency warning by making DSA support depend on the
> same kconfig symbols that NET_DSA depend on.
>
> warning: (NET_DSA_TAG_DSA && NET_DSA_TAG_EDSA && NET_DSA_TAG_TRAILER) selects NET_DSA which has unmet direct dependencies (NET && NETDEVICES && !S390)
This perhaps ought to be abstracted into a HAVE_NET_DSA rather than
reepated here. Also, in net-next NET_DSA still depends on EXPERIMENTAL,
which should be removed.
Ben.
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> net/dsa/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20121126.orig/net/dsa/Kconfig
> +++ linux-next-20121126/net/dsa/Kconfig
> @@ -9,6 +9,7 @@ config NET_DSA
>
>
> menu "Distributed Switch Architecture support"
> + depends on NETDEVICES && !S390
>
> # tagging formats
> config NET_DSA_TAG_DSA
--
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
* [PATCH net-next:master 20/25] net/dsa: make DSA tagging depend on NETDEVICES and !S390
From: Randy Dunlap @ 2012-11-26 18:50 UTC (permalink / raw)
To: Viresh Kumar; +Cc: kbuild test robot, Ben Hutchings, davem, netdev
In-Reply-To: <CAKohpo=r2ZTp5uSp_5duc+zwWvkkwr8dMbz+Yn=WC+ngFy3-0g@mail.gmail.com>
From: Randy Dunlap <rdunlap@infradead.org>
Fix kconfig dependency warning by making DSA support depend on the
same kconfig symbols that NET_DSA depend on.
warning: (NET_DSA_TAG_DSA && NET_DSA_TAG_EDSA && NET_DSA_TAG_TRAILER) selects NET_DSA which has unmet direct dependencies (NET && NETDEVICES && !S390)
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
net/dsa/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20121126.orig/net/dsa/Kconfig
+++ linux-next-20121126/net/dsa/Kconfig
@@ -9,6 +9,7 @@ config NET_DSA
menu "Distributed Switch Architecture support"
+ depends on NETDEVICES && !S390
# tagging formats
config NET_DSA_TAG_DSA
^ permalink raw reply
* Re: [PATCH] bonding: in balance-rr mode, set curr_active_slave only if it is up
From: Jay Vosburgh @ 2012-11-26 18:36 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, Andy Gospodarek, linux-kernel
In-Reply-To: <20121122125202.14252C35B8@unicorn.suse.cz>
Michal Kubecek <mkubecek@suse.cz> wrote:
>If all slaves of a balance-rr bond with ARP monitor are enslaved
>with down link state, bond keeps down state even after slaves
>go up.
>
>This is caused by bond_enslave() setting curr_active_slave to
>first slave not taking into account its link state. As
>bond_loadbalance_arp_mon() uses curr_active_slave to identify
>whether slave's down->up transition should update bond's link
>state, bond stays down even if slaves are up (until first slave
>goes from up to down at least once).
The bond_loadbalance_arp_mon function actually uses
curr_active_slave to determine whether or not to do a "failover" (select
a new active slave), which in turn will call bond_set_carrier() from
within bond_select_active_slave().
Other than that nitpick about the description, I see how setting
curr_active_slave to a down slave would cause loadbalance_arp_mon to
skip the "failover" step (because it presumes that an active slave is
always up, and therefore no new one needs to be selected), and thus skip
setting the master's carrier state.
-J
>Before commit f31c7937 "bonding: start slaves with link down for
>ARP monitor", this was masked by slaves always starting in UP
>state with ARP monitor (and MII monitor not relying on
>curr_active_slave being NULL if there is no slave up).
>
>Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
> drivers/net/bonding/bond_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 5f5b69f..c8bff3e 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -1838,7 +1838,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
> * anyway (it holds no special properties of the bond device),
> * so we can change it without calling change_active_interface()
> */
>- if (!bond->curr_active_slave)
>+ if (!bond->curr_active_slave && new_slave->link == BOND_LINK_UP)
> bond->curr_active_slave = new_slave;
>
> break;
>--
>1.7.10.4
>
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [Pv-drivers] [PATCH 471/493] net: remove use of __devexit
From: Dmitry Torokhov @ 2012-11-26 17:39 UTC (permalink / raw)
To: Bill Pemberton
Cc: Jiri Slaby, Michael S. Tsirkin, VMware, Inc., virtualization,
Maciej W. Rozycki, Christian Lamparter, Hin-Tak Leung,
Luciano Coelho, Stefano Brivio, libertas-dev, Dan Williams,
ath5k-devel, Luis R. Rodriguez, linux-hippi, Nick Kossifidis,
Francois Romieu, Herton Ronaldo Krzesinski, Stanislav Yakovlev,
b43-dev, Samuel Ortiz, John W. Linville, linux-can, xen-devel,
Marc
In-Reply-To: <1353349642-3677-471-git-send-email-wfp5p@virginia.edu>
On Mon, Nov 19, 2012 at 01:27:00PM -0500, Bill Pemberton wrote:
> CONFIG_HOTPLUG is going away as an option so __devexit is no
> longer needed.
...
> drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
For VMXNET3:
Acked-by: Dmitry Torokhov <dtor@vmware.com>
Thanks,
Dmitry
^ permalink raw reply
* Re: [Pv-drivers] [PATCH 203/493] net: remove use of __devinit
From: Dmitry Torokhov @ 2012-11-26 17:38 UTC (permalink / raw)
To: Bill Pemberton
Cc: xen-devel, VMware, Inc., gregkh, Francois Romieu, virtualization,
linux-hippi, Maciej W. Rozycki, netdev, Krzysztof Halasa
In-Reply-To: <1353349642-3677-203-git-send-email-wfp5p@virginia.edu>
On Mon, Nov 19, 2012 at 01:22:32PM -0500, Bill Pemberton wrote:
> CONFIG_HOTPLUG is going away as an option so __devinit is no longer
> needed.
...
> drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
For VMXNET3:
Acked-by: Dmitry Torokhov <dtor@vmware.com>
Thanks,
Dmitry
^ permalink raw reply
* Re: [net-next RFC] pktgen: don't wait for the device who doesn't free skb immediately after sent
From: Stephen Hemminger @ 2012-11-26 17:37 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, netdev, linux-kernel, virtualization, davem
In-Reply-To: <1353916612-6357-1-git-send-email-jasowang@redhat.com>
On Mon, 26 Nov 2012 15:56:52 +0800
Jason Wang <jasowang@redhat.com> wrote:
> Some deivces do not free the old tx skbs immediately after it has been sent
> (usually in tx interrupt). One such example is virtio-net which optimizes for
> virt and only free the possible old tx skbs during the next packet sending. This
> would lead the pktgen to wait forever in the refcount of the skb if no other
> pakcet will be sent afterwards.
>
> Solving this issue by introducing a new flag IFF_TX_SKB_FREE_DELAY which could
> notify the pktgen that the device does not free skb immediately after it has
> been sent and let it not to wait for the refcount to be one.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Another alternative would be using skb_orphan() and skb->destructor.
There are other cases where skb's are not freed right away.
^ permalink raw reply
* Re: [Pv-drivers] [PATCH 086/493] net: remove use of __devexit_p
From: Dmitry Torokhov @ 2012-11-26 17:35 UTC (permalink / raw)
To: Bill Pemberton
Cc: xen-devel, Michael S. Tsirkin, VMware, Inc., gregkh,
virtualization, Francois Romieu, netdev
In-Reply-To: <1353349642-3677-86-git-send-email-wfp5p@virginia.edu>
On Mon, Nov 19, 2012 at 01:20:35PM -0500, Bill Pemberton wrote:
> CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
> needed.
>
> Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Shreyas Bhatewara <sbhatewara@vmware.com>
> Cc: "VMware, Inc." <pv-drivers@vmware.com>
> Cc: Francois Romieu <romieu@fr.zoreil.com>
> Cc: virtualization@lists.linux-foundation.org
> Cc: netdev@vger.kernel.org
> Cc: xen-devel@lists.xensource.com
> ---
> drivers/net/virtio_net.c | 2 +-
> drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
For VMXNET3:
Acked-by: Dmitry Torokhov <dtor@vmware.com>
Thanks,
Dmitry
^ permalink raw reply
* Re: BQL support in gianfar causes network hickup
From: Eric Dumazet @ 2012-11-26 17:17 UTC (permalink / raw)
To: Keitel, Tino (ALC NetworX GmbH)
Cc: Tino Keitel, Paul Gortmaker, netdev@vger.kernel.org
In-Reply-To: <9AA65D849A88EB44B5D9B6A8BA098E23040A60D6EE6F@Exchange1.lawo.de>
On Mon, 2012-11-26 at 18:08 +0100, Keitel, Tino (ALC NetworX GmbH)
wrote:
> On Mo, 2012-11-26 at 08:34 -0800, Eric Dumazet wrote:
> > On Mon, 2012-11-26 at 11:01 +0100, Tino Keitel wrote:
> > > On Sat, Nov 24, 2012 at 15:43:36 -0800, Eric Dumazet wrote:
> > >
> > > [...]
> > >
> > > > Hmm, I wonder if BQL makes a particular bug showing more often.
> > > >
> > > > I see gianfar uses a very small watchdog_timeo of 1 second, while many
> > > > drivers use 5 seconds.
> > > >
> > > > What happens if you change this to 5 seconds ?
> > >
> > > I still got the trace and a failing ptp client.
> > >
> >
> > Thanks. Is this bug easy to trigger ?
> >
> > I suspect a core issue and a race, likely to happen on your (non x86)
> > hardware
> >
> > Could you add the following debugging patch ?
>
> No visible difference:
OK it seems you trigger the problem fast !
Please try the following as well :
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 19ac096..77190bf 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -101,7 +101,7 @@
#include "gianfar.h"
-#define TX_TIMEOUT (1*HZ)
+#define TX_TIMEOUT (5*HZ)
const char gfar_driver_version[] = "1.3";
@@ -2465,9 +2465,9 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
struct sk_buff *skb;
int skb_dirtytx;
int tx_ring_size = tx_queue->tx_ring_size;
- int frags = 0, nr_txbds = 0;
+ int frags, nr_txbds;
int i;
- int howmany = 0;
+ int howmany = 0, total_txbds = 0;
int tqi = tx_queue->qindex;
unsigned int bytes_sent = 0;
u32 lstatus;
@@ -2479,7 +2479,6 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
skb_dirtytx = tx_queue->skb_dirtytx;
while ((skb = tx_queue->tx_skbuff[skb_dirtytx])) {
- unsigned long flags;
frags = skb_shinfo(skb)->nr_frags;
@@ -2541,20 +2540,24 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
TX_RING_MOD_MASK(tx_ring_size);
howmany++;
- spin_lock_irqsave(&tx_queue->txlock, flags);
- tx_queue->num_txbdfree += nr_txbds;
- spin_unlock_irqrestore(&tx_queue->txlock, flags);
+ total_txbds += nr_txbds;
}
- /* If we freed a buffer, we can restart transmission, if necessary */
- if (netif_tx_queue_stopped(txq) && tx_queue->num_txbdfree)
- netif_wake_subqueue(dev, tqi);
+ if (howmany) {
+ unsigned long flags;
+ spin_lock_irqsave(&tx_queue->txlock, flags);
+ tx_queue->num_txbdfree += total_txbds;
+ /* If we freed a buffer, we can restart transmission, if necessary */
+ if (netif_tx_queue_stopped(txq))
+ netif_tx_wake_queue(txq);
+ netdev_tx_completed_queue(txq, howmany, bytes_sent);
+ spin_unlock_irqrestore(&tx_queue->txlock, flags);
+ }
/* Update dirty indicators */
tx_queue->skb_dirtytx = skb_dirtytx;
tx_queue->dirty_tx = bdp;
- netdev_tx_completed_queue(txq, howmany, bytes_sent);
return howmany;
}
^ permalink raw reply related
* Re: BQL support in gianfar causes network hickup
From: Keitel, Tino (ALC NetworX GmbH) @ 2012-11-26 17:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tino Keitel, Paul Gortmaker, netdev@vger.kernel.org
In-Reply-To: <1353947677.7553.2.camel@edumazet-glaptop>
On Mo, 2012-11-26 at 08:34 -0800, Eric Dumazet wrote:
> On Mon, 2012-11-26 at 11:01 +0100, Tino Keitel wrote:
> > On Sat, Nov 24, 2012 at 15:43:36 -0800, Eric Dumazet wrote:
> >
> > [...]
> >
> > > Hmm, I wonder if BQL makes a particular bug showing more often.
> > >
> > > I see gianfar uses a very small watchdog_timeo of 1 second, while many
> > > drivers use 5 seconds.
> > >
> > > What happens if you change this to 5 seconds ?
> >
> > I still got the trace and a failing ptp client.
> >
>
> Thanks. Is this bug easy to trigger ?
>
> I suspect a core issue and a race, likely to happen on your (non x86)
> hardware
>
> Could you add the following debugging patch ?
No visible difference:
NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue 0 timed out
------------[ cut here ]------------
WARNING:
at /home/keitelt1/src/git/linux-stable/net/sched/sch_generic.c:255
Modules linked in:
NIP: c02448b0 LR: c02448b0 CTR: c01c19b8
REGS: c7ffbe40 TRAP: 0700 Not tainted (3.7.0-rc6-dirty)
MSR: 00029032 <EE,ME,IR,DR,RI> CR: 22002044 XER: 20000000
TASK = c03dd370[0] 'swapper' THREAD: c03fe000
GPR00: c02448b0 c7ffbef0 c03dd370 0000003f 00000001 c001aea8 00000000
00000001
GPR08: 00000001 c03e0000 00000000 0000009d 22002084 1008eb5c 07ffb000
ffffffff
GPR16: 00000004 c0362c7c c03dfbf8 00200000 c0411ed0 c0411cd0 c0411ad0
ffffffff
GPR24: 00000000 c749e1d8 00000004 c783c1b0 c0400000 c03e0000 c749e000
00000000
NIP [c02448b0] dev_watchdog+0x288/0x298
LR [c02448b0] dev_watchdog+0x288/0x298
Call Trace:
[c7ffbef0] [c02448b0] dev_watchdog+0x288/0x298 (unreliable)
[c7ffbf20] [c00267f8] call_timer_fn+0x6c/0xd8
[c7ffbf50] [c00269e4] run_timer_softirq+0x180/0x1f8
[c7ffbfa0] [c0021144] __do_softirq+0xc4/0x160
[c7ffbff0] [c000d0b8] call_do_softirq+0x14/0x24
[c03ffe00] [c00058e8] do_softirq+0x8c/0xb8
[c03ffe20] [c0021358] irq_exit+0x98/0xb4
[c03ffe30] [c0009fb0] timer_interrupt+0x158/0x170
[c03ffe50] [c000f02c] ret_from_except+0x0/0x14
--- Exception: 901 at _raw_spin_unlock_irq+0x3c/0x78
LR = _raw_spin_unlock_irq+0x2c/0x78
[c03fff20] [c00434c8] finish_task_switch.constprop.69+0x5c/0xdc
[c03fff40] [c02d354c] __schedule+0x1e0/0x410
[c03fff90] [c02d3a78] schedule_preempt_disabled+0x18/0x30
[c03fffa0] [c000898c] cpu_idle+0xfc/0x100
[c03fffc0] [c03b37b0] start_kernel+0x2dc/0x2f0
[c03ffff0] [00003438] 0x3438
Instruction dump:
7d2903a6 4e800421 80fe01fc 4bffff74 7fc3f378 4bfecb7d 7fc4f378 7fe6fb78
7c651b78 3c60c038 38637280 48090e51 <0fe00000> 39200001 993cc7c9
4bffffb8
---[ end trace c170f56a0503cdd2 ]---
Regards,
Tino
^ permalink raw reply
* Re: BQL support in gianfar causes network hickup
From: Eric Dumazet @ 2012-11-26 16:34 UTC (permalink / raw)
To: Tino Keitel; +Cc: Paul Gortmaker, netdev, Keitel, Tino (ALC NetworX GmbH)
In-Reply-To: <20121126100111.GA3728@mac.home>
On Mon, 2012-11-26 at 11:01 +0100, Tino Keitel wrote:
> On Sat, Nov 24, 2012 at 15:43:36 -0800, Eric Dumazet wrote:
>
> [...]
>
> > Hmm, I wonder if BQL makes a particular bug showing more often.
> >
> > I see gianfar uses a very small watchdog_timeo of 1 second, while many
> > drivers use 5 seconds.
> >
> > What happens if you change this to 5 seconds ?
>
> I still got the trace and a failing ptp client.
>
Thanks. Is this bug easy to trigger ?
I suspect a core issue and a race, likely to happen on your (non x86)
hardware
Could you add the following debugging patch ?
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index aefc150..a8859ec 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -117,7 +117,7 @@ int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,
int ret = NETDEV_TX_BUSY;
/* And release qdisc */
- spin_unlock(root_lock);
+// spin_unlock(root_lock);
HARD_TX_LOCK(dev, txq, smp_processor_id());
if (!netif_xmit_frozen_or_stopped(txq))
@@ -125,7 +125,7 @@ int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,
HARD_TX_UNLOCK(dev, txq);
- spin_lock(root_lock);
+// spin_lock(root_lock);
if (dev_xmit_complete(ret)) {
/* Driver sent out skb successfully or skb was consumed */
^ permalink raw reply related
* RE: [E1000-devel] 82571EB: Detected Hardware Unit Hang
From: Fujinaka, Todd @ 2012-11-26 16:23 UTC (permalink / raw)
To: Joe Jin, Dave, Tushar N
Cc: netdev@vger.kernel.org, e1000-devel@lists.sf.net,
linux-kernel@vger.kernel.org, Mary Mcgrath
In-Reply-To: <50AB8471.7080607@oracle.com>
On Tue, 20 Nov 2012, Joe Jin wrote:
> On 11/20/12 16:59, Dave, Tushar N wrote:
>> Have you power off the system completely after modifying eeprom? If not please do so.
>
> Hi Tushar,
>
> Seems not works for me, would you please help to check what is wrong of my operations?
...
> # lspci -s 0000:52:00.1 -vvv
> 52:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
> <--snip-->
> Capabilities: [e0] Express (v1) Endpoint, MSI 00
> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
^^^^^^^^^^^^^^^^^^^^
> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> MaxPayload 128 bytes, MaxReadReq 4096 bytes
> ^^^^^^^^^^^^^^^^^^^^^
>
<--snip-->
If you look at the previous section, DevCap, you'll see that it's
correctly advertising 256 bytes but the system is negotiating 128 for
the link to the Ethernet controller. Things on the "other" side of the
link are controlled outside of the e1000 driver.
Tushar's first suggestion was to check the PCIe payload settings in the
entire chain. Have you done that? Mismatches will cause hangs.
Todd Fujinaka
Technical Marketing Engineer
LAN Access Division (LAD)
Intel Corporation
todd.fujinaka@intel.com
(503) 712-4565
^ permalink raw reply
* Re: [PATCH v2] atm: br2684: Fix excessive queue bloat
From: David Woodhouse @ 2012-11-26 16:20 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, John Crispin, Dave Täht, Chas Williams (CONTRACTOR),
Jesper Brouer
In-Reply-To: <Pine.LNX.4.64.1211261504240.17614@ask.diku.dk>
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
On Mon, 2012-11-26 at 15:16 +0100, Jesper Dangaard Brouer wrote:
> Nice work David Woodhouse. What OpenWRT supported box have this
> hardware? (I want one so I can play with it ;-))
I'm using a Traverse Geos:
http://www.traverse.com.au/geos11-adsl2-x86-router-appliance
http://www.traverse.com.au/geos21-dual-adsl2-x86-router-appliance
Other boxes with real ADSL (like lantiq boxes) should also work.
Note that I don't actually *use* PPPoEoA (of which this is the EoA
part). I just do PPPoA, which is far more sensible and doesn't have MTU
issues.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: [REGRESSION] r8169: jumbo fixes caused jumbo regressions!
From: Kirill Smelkov @ 2012-11-26 16:19 UTC (permalink / raw)
To: Hayes Wang, Realtek linux nic maintainers
Cc: Francois Romieu, David S. Miller, Greg Kroah-Hartman, netdev
In-Reply-To: <20121114092530.GA22323@tugrik.mns.mnsspb.ru>
On Wed, Nov 14, 2012 at 01:25:30PM +0400, Kirill Smelkov wrote:
> On Tue, Nov 13, 2012 at 11:35:12PM +0100, Francois Romieu wrote:
> > Kirill Smelkov <kirr@mns.spb.ru> :
> > [...]
> > > My test is to stream raw video from 8 PAL cameras to net - 4 for 720x576@25 and
> > > 4 for 360x288@25 which for YUYV format occupies ~ 860 Mbps of bandwidth. The
> > > program to transmit/receive video is here: http://repo.or.cz/w/rawv.git
[...]
> > > (by the way, on atom system, without tx csum offload, half of cpu time
> > > is spent only to calculate checksums...)
> >
> > :o(
>
> yes, that large. In top, my workload is
>
> %sy %id %si
>
> default driver load ~25 ~45 ~27
> (ethtool -k shows
> tx-checksumming: off)
>
> after ~8 ~81 ~11
> `ethtool -K eth0 tx on`
>
>
> that's why the issue is important.
>
>
> > > Now I wonder, where that 6K limit came from and why they say it is now
> > > not possible to use jumbos together with tx csum offload ?
> >
> > Here is an excerpt from a mail where Hayes explained the rules of
> > engagement back in may 2011 (John Lumby and Chris Friesen were Cced then):
>
> Can't find that mail in gmane netdev archive and on google, to restore
> full context. Was that in private?
>
>
> > ! The Max tx sizes for 8168 series are as following:
> > !
> > ! 8168B is 4K bytes.
> > ! 8168C and 8168CP are 6K bytes.
> > ! 8168D and later are 9K bytes.
> > !
> > ! Note that these sizes all include head size. That is, the mtu must less than
> > ! these values.
> > ! You have to enable Jumbo frame feature when the tx size is large, otherwise the
> > ! packet would not be sent. Because the hw doesn't provide the threshold, the
> > ! checking for MTU > 1500 is just for convenience for sw.
>
> This part is clear.
>
>
> > ! The TSO couldn't work with some feature which need to disable hw checksum, such
> > ! as Jumbo frame. The hw checksum have to be disabled in certain situations, so
> > ! the TSO feature should be checked in these situations, too.
>
> I don't enable TSO nor I need it. The text indirectly says that hw
> checksum should be disabled when jumbo frames are used.
[...]
> ~~~~
>
> Hayes, Realtek linux nic maintainers,
>
> could you please confirm that for all 8168C and 8168CP jumbo_max is
> 6K and that when jumbos are used, tx checksumming should be off?
>
> If so, how come my two chips work stable with ~7K jumbos and tx checksum
> offload on (tested this night again for ~16 hours without any problem).
>
> thanks beforehand.
Dear Hayes, Realtek linux nic maintainers,
Two years ago, for current products, I've specifically choosed
motherboard with RTL8111CP, because Linux driver supported large-enough
Jumbo-frames and tx/rx offload.
Now they say that jumbo-frames should be lowered in length and tx
offload is gone, but my nics still work without problems with old ~7K
jumbos and tx checksum offload. To keep current systems working I either
have to choose another hardware, or patch the driver in contrast to what
people say was the info from the manufacturer.
Neither I like to apply risky patches nor change already proved hardware
to something else without a good reason. So please, as Realtek
representatives,
could you please confirm that for all 8168C and 8168CP jumbo_max is
6K and that when jumbos are used, tx checksumming should be off?
Thanks beforehand,
Kirill
P.S. If so, how come my two chips work stable with ~7K jumbos and tx
checksum offload on (last time tested for ~16 hours without any problem)?
^ 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