Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] net: mvneta: properly disable HW PHY polling and ensure adjust_link() works
From: Ethan Tuttle @ 2013-09-05  6:52 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Chény Yves-Gael, Thomas Petazzoni, David S. Miller, netdev,
	linux-arm-kernel, Lior Amsalem, Gregory Clement, Ezequiel Garcia,
	Jochen De Smet, Peter Sanford, Ryan Press, Simon Guinot,
	vdonnefort, stable
In-Reply-To: <20130905064036.GC26000@1wt.eu>

Works like a charm!  Thanks for sharing these.

It may be a while until an alternative to Marvell's uboot is available
for the Mirabox, so it's a shame these patches won't be making it into
the mainline kernel.

Regards,

Ethan

On Wed, Sep 4, 2013 at 11:40 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Thu, Sep 05, 2013 at 08:23:12AM +0200, yves@cheny.fr wrote:
>> Hi Willy,
>> i would be interested too !
>>
>> thx
>> Yves
>>
>> Le 2013-09-05 07:22, Ethan Tuttle a écrit :
>> >Understood.  Ultimately, I'll use this board as a router, and stable
>> >mac addresses would be better than random.  So I would be interested
>> >to try your atag -> device tree patches.  Have they been posted
>> >somewhere I can find them?
>
> OK guys, here they come. Note that they're now simplified since the
> eth* aliases have been added to the dts.
>
> Willy
>

^ permalink raw reply

* [PATCH 2/2] ipv4 igmp: use del_timer_sync instead of del_timer in ip_mc_down
From: Salam Noureddine @ 2013-09-05  6:43 UTC (permalink / raw)
  To: Salam Noureddine, David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev

Delete timers using del_timer_sync in ip_mc_down. Otherwise, it is
possible for the timer to be the last to release its reference to the
in_device and since __in_dev_put doesn't destroy the in_device we
would end up leaking a reference to the net_device and see messages
like the following,

unregister_netdevice: waiting for eth0 to become free. Usage count = 1

Tested on linux-3.4.43.

Signed-off-by: Salam Noureddine <noureddine@aristanetworks.com>
---
 net/ipv4/igmp.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index cd71190..f8c3bbb 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1420,10 +1420,10 @@ void ip_mc_down(struct in_device *in_dev)
 
 #ifdef CONFIG_IP_MULTICAST
 	in_dev->mr_ifc_count = 0;
-	if (del_timer(&in_dev->mr_ifc_timer))
+	if (del_timer_sync(&in_dev->mr_ifc_timer))
 		__in_dev_put(in_dev);
 	in_dev->mr_gq_running = 0;
-	if (del_timer(&in_dev->mr_gq_timer))
+	if (del_timer_sync(&in_dev->mr_gq_timer))
 		__in_dev_put(in_dev);
 	igmpv3_clear_delrec(in_dev);
 #endif
-- 
1.7.4.4

^ permalink raw reply related

* [PATCH 1/2] ipv6 mcast: use del_timer_sync instead of del_timer in ipv6_mc_down
From: Salam Noureddine @ 2013-09-05  6:42 UTC (permalink / raw)
  To: Salam Noureddine, David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev

Delete timers using del_timer_sync in ipv6_mc_down. Otherwise, it is
possible for the timer to be the last to release its reference to the
inet6_dev and since __in6_dev_put doesn't destroy the inet6_dev we
would end up leaking a reference to the net_device and see messages
like the following,

unregister_netdevice: waiting for eth0 to become free. Usage count = 1

Tested on linux-3.4.43.

Signed-off-by: Salam Noureddine <noureddine@aristanetworks.com>
---
 net/ipv6/mcast.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 99cd65c..5c8d49d 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -2277,12 +2277,12 @@ void ipv6_mc_down(struct inet6_dev *idev)
 
 	read_lock_bh(&idev->lock);
 	idev->mc_ifc_count = 0;
-	if (del_timer(&idev->mc_ifc_timer))
+	if (del_timer_sync(&idev->mc_ifc_timer))
 		__in6_dev_put(idev);
 	idev->mc_gq_running = 0;
-	if (del_timer(&idev->mc_gq_timer))
+	if (del_timer_sync(&idev->mc_gq_timer))
 		__in6_dev_put(idev);
-	if (del_timer(&idev->mc_dad_timer))
+	if (del_timer_sync(&idev->mc_dad_timer))
 		__in6_dev_put(idev);
 
 	for (i = idev->mc_list; i; i=i->next)
-- 
1.7.4.4

^ permalink raw reply related

* Re: [PATCH] net: mvneta: properly disable HW PHY polling and ensure adjust_link() works
From: Willy Tarreau @ 2013-09-05  6:40 UTC (permalink / raw)
  To: yves
  Cc: Thomas Petazzoni, Lior Amsalem, Jochen De Smet, Simon Guinot,
	Ryan Press, netdev, vdonnefort, Ethan Tuttle, stable,
	Ezequiel Garcia, Gregory Clement, Peter Sanford, David S. Miller,
	linux-arm-kernel
In-Reply-To: <ca521df880b08225cb34214e3ef0fc2c@cheny.fr>

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

On Thu, Sep 05, 2013 at 08:23:12AM +0200, yves@cheny.fr wrote:
> Hi Willy,
> i would be interested too !
> 
> thx
> Yves
> 
> Le 2013-09-05 07:22, Ethan Tuttle a écrit :
> >Understood.  Ultimately, I'll use this board as a router, and stable
> >mac addresses would be better than random.  So I would be interested
> >to try your atag -> device tree patches.  Have they been posted
> >somewhere I can find them?

OK guys, here they come. Note that they're now simplified since the
eth* aliases have been added to the dts.

Willy


[-- Attachment #2: 0001-ARM-atags-add-support-for-Marvell-s-u-boot.patch --]
[-- Type: text/plain, Size: 1213 bytes --]

>From d8254ce7d6b199eb0114ee1229a066bd24d7f339 Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w@1wt.eu>
Date: Sun, 2 Dec 2012 19:59:28 +0100
Subject: ARM: atags: add support for Marvell's u-boot

Marvell uses a specific atag in its u-boot which includes among other
information the MAC addresses for up to 4 network interfaces.

Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 arch/arm/include/uapi/asm/setup.h | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/include/uapi/asm/setup.h b/arch/arm/include/uapi/asm/setup.h
index 979ff40..d1d0c19 100644
--- a/arch/arm/include/uapi/asm/setup.h
+++ b/arch/arm/include/uapi/asm/setup.h
@@ -143,6 +143,18 @@ struct tag_memclk {
 	__u32 fmemclk;
 };
 
+/* Marvell uboot parameters */
+#define ATAG_MV_UBOOT          0x41000403
+struct tag_mv_uboot {
+	__u32 uboot_version;
+	__u32 tclk;
+	__u32 sysclk;
+	__u32 isUsbHost;
+	__u8  macAddr[4][6];
+	__u16 mtu[4];
+	__u32 nand_ecc;
+};
+
 struct tag {
 	struct tag_header hdr;
 	union {
@@ -165,6 +177,11 @@ struct tag {
 		 * DC21285 specific
 		 */
 		struct tag_memclk	memclk;
+
+		/*
+		 * Marvell specific
+		 */
+		struct tag_mv_uboot	mv_uboot;
 	} u;
 };
 
-- 
1.7.12.2.21.g234cd45.dirty


[-- Attachment #3: 0002-ARM-atags-fdt-retrieve-MAC-addresses-from-Marvell-bo.patch --]
[-- Type: text/plain, Size: 1736 bytes --]

>From f2242fcc35ea1548bab13095a8d82dbf526ba9f7 Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w@1wt.eu>
Date: Sun, 2 Dec 2012 19:56:58 +0100
Subject: ARM: atags/fdt: retrieve MAC addresses from Marvell boot loader

The atags are parsed and if a Marvell atag is found, up to 4 MAC
addresses are extracted there and assigned to node aliases eth0..3
with the name "mac-address".

This was tested on my Mirabox and the two NICs had their correct
address set.

Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 arch/arm/boot/compressed/atags_to_fdt.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
index d1153c8..24b31ae 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -16,7 +16,7 @@ static int node_offset(void *fdt, const char *node_path)
 }
 
 static int setprop(void *fdt, const char *node_path, const char *property,
-		   uint32_t *val_array, int size)
+		   void *val_array, int size)
 {
 	int offset = node_offset(fdt, node_path);
 	if (offset < 0)
@@ -177,6 +177,12 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
 					initrd_start);
 			setprop_cell(fdt, "/chosen", "linux,initrd-end",
 					initrd_start + initrd_size);
+		} else if (atag->hdr.tag == ATAG_MV_UBOOT) {
+			/* This ATAG provides up to 4 MAC addresses */
+			setprop(fdt, "eth0", "mac-address", atag->u.mv_uboot.macAddr[0], 6);
+			setprop(fdt, "eth1", "mac-address", atag->u.mv_uboot.macAddr[1], 6);
+			setprop(fdt, "eth2", "mac-address", atag->u.mv_uboot.macAddr[2], 6);
+			setprop(fdt, "eth3", "mac-address", atag->u.mv_uboot.macAddr[3], 6);
 		}
 	}
 
-- 
1.7.12.2.21.g234cd45.dirty


[-- Attachment #4: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH] net: mvneta: properly disable HW PHY polling and ensure adjust_link() works
From: yves @ 2013-09-05  6:23 UTC (permalink / raw)
  To: Ethan Tuttle
  Cc: Willy Tarreau, Thomas Petazzoni, David S. Miller, netdev,
	linux-arm-kernel, Lior Amsalem, Gregory Clement, Ezequiel Garcia,
	Jochen De Smet, Peter Sanford, Ryan Press, Simon Guinot,
	vdonnefort, stable
In-Reply-To: <CACzLR4uCQhGzgABV2nMG45EQBNsrW8=j5X7x-=eTSUmSvthLxg@mail.gmail.com>

Hi Willy,
i would be interested too !

thx
Yves

Le 2013-09-05 07:22, Ethan Tuttle a écrit :
> Understood.  Ultimately, I'll use this board as a router, and stable
> mac addresses would be better than random.  So I would be interested
> to try your atag -> device tree patches.  Have they been posted
> somewhere I can find them?
> 
> Thanks Willy.
> 
> Ethan
> 
> On Wed, Sep 4, 2013 at 10:12 PM, Willy Tarreau <w@1wt.eu> wrote:
>> Hi,
>> 
>> On Wed, Sep 04, 2013 at 09:14:23PM -0700, Ethan Tuttle wrote:
>>> Just booted with the patch on my Mirabox.  Both interfaces work!
>>> Thank you Thomas.
>>> 
>>> One remaining issue is that the interface which uBoot didn't 
>>> configure
>>> is still getting a random mac address:
>>> 
>>> mvneta d0070000.ethernet eth0: Using hardware mac address 
>>> f0:ad:4e:01:dc:97
>>> mvneta d0074000.ethernet eth1: Using random mac address 
>>> d2:35:dd:c8:99:48
>>> 
>>> This is on 3.11 plus Thomas' patch, which includes the previous fix 
>>> to
>>> "read MAC address from hardware when available".  Perhaps that fix
>>> isn't working with the phylib?
>> 
>> No this is unrelated. The MAC isn't configured by the boot loader when
>> the NIC is not used. U-boot only passes it as a non-standard ATAG. I
>> have some patches to reinject the non-standard atags into the device
>> tree if you absolutely need this, but they're not suited for mainline
>> inclusion from what I understood last time I proposed them (they use
>> a marvell-specific atag header).
>> 
>> Regards,
>> Willy
>> 

^ permalink raw reply

* Re: [ovs-dev] [PATCH v2.38 0/6] MPLS actions and matches
From: Simon Horman @ 2013-09-05  5:31 UTC (permalink / raw)
  To: Jesse Gross; +Cc: dev, netdev, Isaku Yamahata, Ravi K
In-Reply-To: <20130828071432.GA15577@verge.net.au>

On Wed, Aug 28, 2013 at 04:14:32PM +0900, Simon Horman wrote:
> On Fri, Aug 23, 2013 at 01:16:50PM +1000, Simon Horman wrote:
> > Hi,
> > 
> > This series implements MPLS actions and matches based on work by
> > Ravi K, Leo Alterman, Yamahata-san and Joe Stringer.
> > 
> > This series provides two changes
> > 
> > * Provide user-space support for the VLAN/MPLS tag insertion order
> >   up to and including OpenFlow 1.2, and the different ordering
> >   specified from OpenFlow 1.3. In a nutshell the datapath always
> >   uses the OpenFlow 1.3 ordering, which is to always insert tags
> >   immediately after the L2 header, regardless of the presence of other
> >   tags. And ovs-vswtichd provides compatibility for the behaviour up
> >   to OpenFlow 1.2, which is that MPLS tags should follow VLAN tags
> >   if present.
> > 
> > * Adding basic MPLS action and match support to the kernel datapath
> 
> Hi Jesse,
> 
> I'm wondering if you could find some time to look over this series.
> I believe it addresses all the issues you raised with regards to v2.35.

Hi Jesse,

I have checked and I believe this series still applies against the
current master branch. I'm wondering of you could find some time to
review it.

> 
> > Differences between v2.38 and v2.37:
> > 
> > * Rebase for SCTP support
> > * Refactor validate_tp_port() to iterate over eth_types rather
> >   than open-coding the loop. With the addition of SCTP this logic
> >   is now used three times.
> > 
> > 
> > Differences between v2.37 and v2.36:
> > 
> > * Rebase
> > 
> > 
> > Differences between v2.36 and v2.35:
> > 
> > * Rebase
> > 
> > * Do not add set_ethertype() to datapath/actions.c.
> >   As this patch has evolved this function had devolved into
> >   to sets of functionality wrapped into a single function with
> >   only one line of common code. Refactor things to simply
> >   open-code setting the ether type in the two locations where
> >   set_ethertype() was previously used. The aim here is to improve
> >   readability.
> > 
> > * Update setting skb->ethertype after mpls push and pop.
> >   - In the case of push_mpls it should be set unconditionally
> >     as in v2.35 the behaviour of this function to always push
> >     an MPLS LSE before any VLAN tags.
> >   - In the case of mpls_pop eth_p_mpls(skb->protocol) is a better
> >     test than skb->protocol != htons(ETH_P_8021Q) as it will give the
> >     correct behaviour in the presence of other VLAN ethernet types,
> >     for example 0x88a8 which is used by 802.1ad. Moreover, it seems
> >     correct to update the ethernet type if it was previously set
> >     according to the top-most MPLS LSE.
> > 
> > * Deaccelerate VLANs when pushing MPLS tags the
> >   - Since v2.35 MPLS push will insert an MPLS LSE before any VLAN tags.
> >     This means that if an accelerated tag is present it should be
> >     deaccelerated to ensure it ends up in the correct position.
> > 
> > * Update skb->mac_len in push_mpls() so that it will be correct
> >   when used by a subsequent call to pop_mpls().
> > 
> >   As things stand I do not believe this is strictly necessary as
> >   ovs-vswitchd will not send a pop MPLS action after a push MPLS action.
> >   However, I have added this in order to code more defensively as I believe
> >   that if such a sequence did occur it would be rather unobvious why
> >   it didn't work.
> > 
> > * Do not add skb_cow_head() call in push_mpls().
> >   It is unnecessary as there is a make_writable() call.
> >   This change was also made in v2.30 but some how the
> >   code regressed between then and v2.35.
> > 
> > 
> > Differences between v2.35 and v2.34:
> > 
> > * Add support for the tag ordering specified up until OpenFlow 1.2 and
> >   the ordering specified from OpenFlow 1.3.
> > 
> > * Correct error in datapath patch's handling of GSO in the presence
> >   of MPLS and absence of VLANs.
> > 
> > 
> > Patch overview:
> > 
> > * The first 5 patches of this series are new,
> >   adding support for different tag ordering.
> > * The last patch is a revised version of the patch to add MPLS support
> >   to the datapath. It has been updated to use OpenFlow 1.3 tag ordering
> >   and resolve a GSO handling bug: both mentioned above. Its change log
> >   includes a history of changes.
> > 
> > 
> > To aid review this series is available in git at:
> > 
> > git://github.com/horms/openvswitch.git devel/mpls-v2.38
> > 
> > 
> > Patch list and overall diffstat:
> > 
> > Joe Stringer (5):
> >   odp: Only pass vlan_tci to commit_vlan_action()
> >   odp: Allow VLAN actions after MPLS actions
> >   ofp-actions: Add OFPUTIL_OFPAT13_PUSH_MPLS
> >   ofp-actions: Add separate OpenFlow 1.3 action parser
> >   lib: Push MPLS tags in the OpenFlow 1.3 ordering
> > 
> > Simon Horman (1):
> >   datapath: Add basic MPLS support to kernel
> > 
> >  datapath/Modules.mk                             |    1 +
> >  datapath/actions.c                              |  121 +++++-
> >  datapath/datapath.c                             |  259 +++++++++++--
> >  datapath/datapath.h                             |    9 +
> >  datapath/flow.c                                 |   58 ++-
> >  datapath/flow.h                                 |   17 +-
> >  datapath/linux/compat/gso.c                     |   50 ++-
> >  datapath/linux/compat/gso.h                     |   39 ++
> >  datapath/linux/compat/include/linux/netdevice.h |   12 -
> >  datapath/linux/compat/netdevice.c               |   28 --
> >  datapath/mpls.h                                 |   15 +
> >  datapath/vport-lisp.c                           |    1 +
> >  datapath/vport-netdev.c                         |   44 ++-
> >  include/linux/openvswitch.h                     |    7 +-
> >  lib/flow.c                                      |    2 +-
> >  lib/odp-util.c                                  |   22 +-
> >  lib/odp-util.h                                  |    4 +-
> >  lib/ofp-actions.c                               |   68 +++-
> >  lib/ofp-parse.c                                 |    1 +
> >  lib/ofp-util.c                                  |    3 +
> >  lib/ofp-util.h                                  |    1 +
> >  lib/packets.c                                   |   10 +-
> >  lib/packets.h                                   |    2 +-
> >  ofproto/ofproto-dpif-xlate.c                    |  103 ++++--
> >  ofproto/ofproto-dpif-xlate.h                    |    5 +
> >  tests/ofproto-dpif.at                           |  446 +++++++++++++++++++++++
> >  26 files changed, 1198 insertions(+), 130 deletions(-)
> >  create mode 100644 datapath/mpls.h
> > 
> > -- 
> > 1.7.10.4
> > 
> > _______________________________________________
> > dev mailing list
> > dev@openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply

* linux-next: manual merge of the net-next tree with Linus' tree
From: Stephen Rothwell @ 2013-09-05  5:23 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Hannes Frederic Sowa, Nicolas Dichtel

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/ipv6/sit.c between commit 3d483058c8c8 ("ipv6: wire up
skb->encapsulation") from Linus' tree and commit 8b7ed2d91d6a
("iptunnels: remove net arg from iptunnel_xmit()") from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc net/ipv6/sit.c
index 21b25dd,19abcc9..0000000
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@@ -886,13 -881,8 +879,13 @@@ static netdev_tx_t ipip6_tunnel_xmit(st
  		ttl = iph6->hop_limit;
  	tos = INET_ECN_encapsulate(tos, ipv6_get_dsfield(iph6));
  
 +	if (likely(!skb->encapsulation)) {
 +		skb_reset_inner_headers(skb);
 +		skb->encapsulation = 1;
 +	}
 +
- 	err = iptunnel_xmit(dev_net(dev), rt, skb, fl4.saddr, fl4.daddr,
- 			    IPPROTO_IPV6, tos, ttl, df);
+ 	err = iptunnel_xmit(rt, skb, fl4.saddr, fl4.daddr, IPPROTO_IPV6, tos,
+ 			    ttl, df, !net_eq(tunnel->net, dev_net(dev)));
  	iptunnel_xmit_stats(err, &dev->stats, dev->tstats);
  	return NETDEV_TX_OK;
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH] net: mvneta: properly disable HW PHY polling and ensure adjust_link() works
From: Ethan Tuttle @ 2013-09-05  5:22 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Thomas Petazzoni, David S. Miller, netdev, linux-arm-kernel,
	Lior Amsalem, Gregory Clement, Ezequiel Garcia, Jochen De Smet,
	Peter Sanford, Chény Yves-Gael, Ryan Press, Simon Guinot,
	vdonnefort, stable
In-Reply-To: <20130905051223.GB26000@1wt.eu>

Understood.  Ultimately, I'll use this board as a router, and stable
mac addresses would be better than random.  So I would be interested
to try your atag -> device tree patches.  Have they been posted
somewhere I can find them?

Thanks Willy.

Ethan

On Wed, Sep 4, 2013 at 10:12 PM, Willy Tarreau <w@1wt.eu> wrote:
> Hi,
>
> On Wed, Sep 04, 2013 at 09:14:23PM -0700, Ethan Tuttle wrote:
>> Just booted with the patch on my Mirabox.  Both interfaces work!
>> Thank you Thomas.
>>
>> One remaining issue is that the interface which uBoot didn't configure
>> is still getting a random mac address:
>>
>> mvneta d0070000.ethernet eth0: Using hardware mac address f0:ad:4e:01:dc:97
>> mvneta d0074000.ethernet eth1: Using random mac address d2:35:dd:c8:99:48
>>
>> This is on 3.11 plus Thomas' patch, which includes the previous fix to
>> "read MAC address from hardware when available".  Perhaps that fix
>> isn't working with the phylib?
>
> No this is unrelated. The MAC isn't configured by the boot loader when
> the NIC is not used. U-boot only passes it as a non-standard ATAG. I
> have some patches to reinject the non-standard atags into the device
> tree if you absolutely need this, but they're not suited for mainline
> inclusion from what I understood last time I proposed them (they use
> a marvell-specific atag header).
>
> Regards,
> Willy
>

^ permalink raw reply

* linux-next: manual merge of the net-next tree with Linus' tree
From: Stephen Rothwell @ 2013-09-05  5:19 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, Daniel Borkmann

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/bridge/br_multicast.c between commit 2d98c29b6fb3 ("net: bridge:
convert MLDv2 Query MRC into msecs_to_jiffies for max_delay") from Linus'
tree and commit e3f5b17047de ("net: ipv6: mld: get rid of MLDV2_MRC and
simplify calculation") from the net-next tree.

I just used the net-next tree version and can carry the fix as necessary
(no action is required).


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH v2 net-next] pkt_sched: fq: Fair Queue packet scheduler
From: Jason Wang @ 2013-09-05  5:16 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: David Miller, netdev, Yuchung Cheng, Neal Cardwell,
	Michael S. Tsirkin
In-Reply-To: <1378352479.11205.5.camel@edumazet-glaptop>

On 09/05/2013 11:41 AM, Eric Dumazet wrote:
> On Thu, 2013-09-05 at 11:07 +0800, Jason Wang wrote:
>
>> > tc -s -d qdisc
>> > qdisc fq 8001: dev eth0 root refcnt 2 [Unknown qdisc, optlen=64]
>> >  Sent 6680760347 bytes 4431855 pkt (dropped 0, overlimits 0 requeues 0)
>> >  backlog 0b 0p requeues 0
>> > 
>> > btw, is the fq support for tc merged into iproute2? Looks like I can't
>> > find them.
> Yep its there on net-next-3.11 branch

Thanks. With the tc in this branch, after test I get:

./tc -s -d qdisc
qdisc fq 8001: dev eth0 root refcnt 2 limit 10000p flow_limit 100p
buckets 1024 quantum 3028 initial_quantum 15140
 Sent 3545374119 bytes 2341785 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  5 flows (0 inactive, 0 throttled)
  0 gc, 37 highprio, 51805 throttled

^ permalink raw reply

* Re: [PATCH] net: mvneta: properly disable HW PHY polling and ensure adjust_link() works
From: Willy Tarreau @ 2013-09-05  5:12 UTC (permalink / raw)
  To: Ethan Tuttle
  Cc: Thomas Petazzoni, Lior Amsalem, Jochen De Smet, Simon Guinot,
	Ryan Press, netdev, vdonnefort, stable, Ezequiel Garcia,
	Chény Yves-Gael, Gregory Clement, Peter Sanford,
	David S. Miller, linux-arm-kernel
In-Reply-To: <CACzLR4uDQK2bkcEJQXLe805EfSA8=eF+YH-FTYovHA0q+8Y9NA@mail.gmail.com>

Hi,

On Wed, Sep 04, 2013 at 09:14:23PM -0700, Ethan Tuttle wrote:
> Just booted with the patch on my Mirabox.  Both interfaces work!
> Thank you Thomas.
> 
> One remaining issue is that the interface which uBoot didn't configure
> is still getting a random mac address:
> 
> mvneta d0070000.ethernet eth0: Using hardware mac address f0:ad:4e:01:dc:97
> mvneta d0074000.ethernet eth1: Using random mac address d2:35:dd:c8:99:48
> 
> This is on 3.11 plus Thomas' patch, which includes the previous fix to
> "read MAC address from hardware when available".  Perhaps that fix
> isn't working with the phylib?

No this is unrelated. The MAC isn't configured by the boot loader when
the NIC is not used. U-boot only passes it as a non-standard ATAG. I
have some patches to reinject the non-standard atags into the device
tree if you absolutely need this, but they're not suited for mainline
inclusion from what I understood last time I proposed them (they use
a marvell-specific atag header).

Regards,
Willy

^ permalink raw reply

* Re: [E1000-devel] [net-next v4 7/8] i40e: sysfs and debugfs interfaces
From: Stephen Hemminger @ 2013-09-05  4:55 UTC (permalink / raw)
  To: Nelson, Shannon
  Cc: Kirsher, Jeffrey T, e1000-devel@lists.sourceforge.net,
	netdev@vger.kernel.org, Brandeburg, Jesse, gospo@redhat.com,
	davem@davemloft.net, sassmann@redhat.com
In-Reply-To: <FC41C24E35F18A40888AACA1A36F3E416C61CF23@FMSMSX102.amr.corp.intel.com>

I am very busy with work and personal issues. Don't depend on my time.
More surprising is that others did not see the same things.
Your business is your problem.

On Wed, Sep 4, 2013 at 6:25 PM, Nelson, Shannon
<shannon.nelson@intel.com> wrote:
>> -----Original Message-----
>> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
>> Sent: Wednesday, September 04, 2013 5:38 PM
>>
>
> [ ... many good comments on i40e_sysfs.c ... ]
>
> Hi Stephen,
>
> Thanks for your comments.  Frankly, we were hoping for this kind of feedback when we posted the first version of this driver a couple of months ago, with the intent of clearing up any issues in time to get settled and accepted about now.  Yes, this is driven by business reasons that this list doesn't need to hear me whine about, but that is our reality.
>
> We'll be happy to work with you on- or off-list over the next few days to come up with a good resolution to your concerns, and from that we can publish follow-on patches to this current submission.  We should be able to get it settled and done quickly and without too much fuss.  I won't be at Plumber's this year, but perhaps Jesse or John can get together with you and other concerned sysfs folks if needed to finalize any issues.
>
> Will this work for you?
>
> Thanks,
> sln
>

^ permalink raw reply

* Re: [rfc] suspicious indentation in do_tcp_setsockopt
From: Joe Perches @ 2013-09-05  4:53 UTC (permalink / raw)
  To: Dave Jones; +Cc: David Miller, netdev, Julia Lawall
In-Reply-To: <20130905044318.GA22806@redhat.com>

On Thu, 2013-09-05 at 00:43 -0400, Dave Jones wrote:
> On Thu, Sep 05, 2013 at 12:39:07AM -0400, David Miller wrote:
>  > From: Dave Jones <davej@redhat.com>
>  > Date: Thu, 5 Sep 2013 00:20:45 -0400
>  > 
>  > > What's the intent here ?
>  > 
>  > This stuff is great, do you have a script that looks for this false
>  > indentation pattern?
> 
> Coverity.

Good stuff.

> I'm doing daily builds with it now, in the hope of trying
> to catch things faster, but there's a *ton* of old stuff in there
> like this that needs sorting through, because it seems to have strange
> of notions of what a 'new' bug is.

I think scripts/coccinelle/misc/ifcol.cocci
does something similar.

^ permalink raw reply

* Re: [rfc] suspicious indentation in do_tcp_setsockopt
From: Dave Jones @ 2013-09-05  4:43 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20130905.003907.664285605568829856.davem@davemloft.net>

On Thu, Sep 05, 2013 at 12:39:07AM -0400, David Miller wrote:
 > From: Dave Jones <davej@redhat.com>
 > Date: Thu, 5 Sep 2013 00:20:45 -0400
 > 
 > > What's the intent here ?
 > 
 > This stuff is great, do you have a script that looks for this false
 > indentation pattern?

Coverity. I'm doing daily builds with it now, in the hope of trying
to catch things faster, but there's a *ton* of old stuff in there
like this that needs sorting through, because it seems to have strange
of notions of what a 'new' bug is.

	Dave

^ permalink raw reply

* Re: [rfc] suspicious indentation in do_tcp_setsockopt
From: Joe Perches @ 2013-09-05  4:43 UTC (permalink / raw)
  To: Dave Jones, Yuchung Cheng; +Cc: netdev, Neal Cardwell
In-Reply-To: <20130905042045.GD15824@redhat.com>

(Adding Yuchung Cheng and Neal Cardwell as the
 author and acker of the patch)

On Thu, 2013-09-05 at 00:20 -0400, Dave Jones wrote:
> What's the intent here ?
> 
> This ?

I think the first is most likely.

> 
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index b2f6c74..95544e4 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -2454,10 +2454,11 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
>  	case TCP_THIN_DUPACK:
>  		if (val < 0 || val > 1)
>  			err = -EINVAL;
> -		else
> +		else {
>  			tp->thin_dupack = val;
>  			if (tp->thin_dupack)
>  				tcp_disable_early_retrans(tp);
> +		}
>  		break;
>  
>  	case TCP_REPAIR:
> 
> Or this ...
> 
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index b2f6c74..187c5a4 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -2456,8 +2456,9 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
>  			err = -EINVAL;
>  		else
>  			tp->thin_dupack = val;
> -			if (tp->thin_dupack)
> -				tcp_disable_early_retrans(tp);
> +
> +		if (tp->thin_dupack)
> +			tcp_disable_early_retrans(tp);
>  		break;
>  
>  	case TCP_REPAIR:
> 
> 
> I'll submit the right patch in the right form once I know what was intended.
> 
> The former seems more 'correct' to me, but I'm unsure if that could break something.
> 
> 	Dave
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply

* Re: [rfc] suspicious indentation in do_tcp_setsockopt
From: David Miller @ 2013-09-05  4:39 UTC (permalink / raw)
  To: davej; +Cc: netdev
In-Reply-To: <20130905042045.GD15824@redhat.com>

From: Dave Jones <davej@redhat.com>
Date: Thu, 5 Sep 2013 00:20:45 -0400

> What's the intent here ?

This stuff is great, do you have a script that looks for this false
indentation pattern?

^ permalink raw reply

* Re: [E1000-devel] [net-next v4 7/8] i40e: sysfs and debugfs interfaces
From: David Miller @ 2013-09-05  4:37 UTC (permalink / raw)
  To: jesse.brandeburg
  Cc: shannon.nelson, stephen, jeffrey.t.kirsher, e1000-devel, netdev,
	gospo, sassmann
In-Reply-To: <1378354121.26131.4.camel@jbrandeb-mobl2>

From: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
Date: Thu, 5 Sep 2013 04:08:39 +0000

> On Wed, 2013-09-04 at 23:19 -0400, David Miller wrote:
>> You will fix the problems people are reporting with this patch series
>> before I apply it.
> 
> Okay, the quickest path to that might be to drop the sysfs patch for
> now.  If that is acceptable I will re-spin the patches tonight.

You're just going to ask me to add the sysfs code later, just make
the appropriate fixes.

Thanks.

^ permalink raw reply

* [rfc] suspicious indentation in do_tcp_setsockopt
From: Dave Jones @ 2013-09-05  4:20 UTC (permalink / raw)
  To: netdev

What's the intent here ?

This ?


diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index b2f6c74..95544e4 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2454,10 +2454,11 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
 	case TCP_THIN_DUPACK:
 		if (val < 0 || val > 1)
 			err = -EINVAL;
-		else
+		else {
 			tp->thin_dupack = val;
 			if (tp->thin_dupack)
 				tcp_disable_early_retrans(tp);
+		}
 		break;
 
 	case TCP_REPAIR:

Or this ...

diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index b2f6c74..187c5a4 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2456,8 +2456,9 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
 			err = -EINVAL;
 		else
 			tp->thin_dupack = val;
-			if (tp->thin_dupack)
-				tcp_disable_early_retrans(tp);
+
+		if (tp->thin_dupack)
+			tcp_disable_early_retrans(tp);
 		break;
 
 	case TCP_REPAIR:


I'll submit the right patch in the right form once I know what was intended.

The former seems more 'correct' to me, but I'm unsure if that could break something.

	Dave

^ permalink raw reply related

* Re: [PATCH] net: mvneta: properly disable HW PHY polling and ensure adjust_link() works
From: Ethan Tuttle @ 2013-09-05  4:14 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Thomas Petazzoni, David S. Miller, netdev, linux-arm-kernel,
	Lior Amsalem, Gregory Clement, Ezequiel Garcia, Jochen De Smet,
	Peter Sanford, Chény Yves-Gael, Ryan Press, Simon Guinot,
	vdonnefort, stable
In-Reply-To: <20130904163245.GI20552@1wt.eu>

Just booted with the patch on my Mirabox.  Both interfaces work!
Thank you Thomas.

One remaining issue is that the interface which uBoot didn't configure
is still getting a random mac address:

mvneta d0070000.ethernet eth0: Using hardware mac address f0:ad:4e:01:dc:97
mvneta d0074000.ethernet eth1: Using random mac address d2:35:dd:c8:99:48

This is on 3.11 plus Thomas' patch, which includes the previous fix to
"read MAC address from hardware when available".  Perhaps that fix
isn't working with the phylib?

Thanks again,

Ethan

On Wed, Sep 4, 2013 at 9:32 AM, Willy Tarreau <w@1wt.eu> wrote:
>
> Hi Thomas!
>
> On Wed, Sep 04, 2013 at 04:21:18PM +0200, Thomas Petazzoni wrote:
> > This commit fixes a long-standing bug that has been reported by many
> > users: on some Armada 370 platforms, only the network interface that
> > has been used in U-Boot to tftp the kernel works properly in
> > Linux. The other network interfaces can see a 'link up', but are
> > unable to transmit data. The reports were generally made on the Armada
> > 370-based Mirabox, but have also been given on the Armada 370-RD
> > board.
> (...)
> > This patch has been tested on Armada 370 Mirabox, and now both network
> > interfaces are usable after boot.
>
> Just as a complementary check, I can also confirm that the OpenBlocks
> AX3 continues to work fine after this change.
>
> Best regards!
> Willy
>

^ permalink raw reply

* [PATCH] Add missing braces to multiline if in cfctrl_linkup_request
From: Dave Jones @ 2013-09-05  4:11 UTC (permalink / raw)
  To: dmitry.tarnyagin; +Cc: netdev

The indentation here implies this was meant to be a multi-line if.

Introduced several years back in commit c85c2951d4da1236e32f1858db418221e624aba5
("caif: Handle dev_queue_xmit errors.")

Signed-off-by: Dave Jones <davej@fedoraproject.org>

diff --git a/net/caif/cfctrl.c b/net/caif/cfctrl.c
index 2bd4b58..0f45522 100644
--- a/net/caif/cfctrl.c
+++ b/net/caif/cfctrl.c
@@ -293,9 +293,10 @@ int cfctrl_linkup_request(struct cflayer *layer,
 
 		count = cfctrl_cancel_req(&cfctrl->serv.layer,
 						user_layer);
-		if (count != 1)
+		if (count != 1) {
 			pr_err("Could not remove request (%d)", count);
 			return -ENODEV;
+		}
 	}
 	return 0;
 }

^ permalink raw reply related

* Re: [E1000-devel] [net-next v4 7/8] i40e: sysfs and debugfs interfaces
From: Brandeburg, Jesse @ 2013-09-05  4:08 UTC (permalink / raw)
  To: David Miller
  Cc: Nelson, Shannon, stephen@networkplumber.org, Kirsher, Jeffrey T,
	e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
	gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <20130904.231950.956676623509287249.davem@davemloft.net>

On Wed, 2013-09-04 at 23:19 -0400, David Miller wrote:
> You will fix the problems people are reporting with this patch series
> before I apply it.

Okay, the quickest path to that might be to drop the sysfs patch for
now.  If that is acceptable I will re-spin the patches tonight.


^ permalink raw reply

* [PATCH] Add missing braces to ath10k_pci_tx_pipe_cleanup
From: Dave Jones @ 2013-09-05  3:51 UTC (permalink / raw)
  To: netdev; +Cc: kvalo, linville, ath10k, linux-wireless

The indentation here implies this was meant to be a multi-statement if, but it lacks the braces.

Signed-off-by: Dave Jones <davej@fedoraproject.org>

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 33af467..31b69d3 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1200,7 +1200,7 @@ static void ath10k_pci_tx_pipe_cleanup(struct hif_ce_pipe_info *pipe_info)
 
 	while (ath10k_ce_cancel_send_next(ce_hdl, (void **)&netbuf,
 					  &ce_data, &nbytes, &id) == 0) {
-		if (netbuf != CE_SENDLIST_ITEM_CTXT)
+		if (netbuf != CE_SENDLIST_ITEM_CTXT) {
 			/*
 			 * Indicate the completion to higer layer to free
 			 * the buffer
@@ -1209,6 +1209,7 @@ static void ath10k_pci_tx_pipe_cleanup(struct hif_ce_pipe_info *pipe_info)
 			ar_pci->msg_callbacks_current.tx_completion(ar,
 								    netbuf,
 								    id);
+		}
 	}
 }
 

^ permalink raw reply related

* Add missing braces in bnx2x:bnx2x_link_initialize
From: Dave Jones @ 2013-09-05  3:46 UTC (permalink / raw)
  To: netdev; +Cc: eilong

The indentation here implies that the intent was for this to be a multiline if.
Introduced a few years ago in commit ec146a6f019923819f5ca381980248b6d154ca1a ("bnx2x: Modify XGXS functions")

Signed-off-by: Dave Jones <davej@fedoraproject.org>

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
index 9d64b98..6645684 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
@@ -6501,12 +6501,13 @@ static int bnx2x_link_initialize(struct link_params *params,
 		struct bnx2x_phy *phy = &params->phy[INT_PHY];
 		if (vars->line_speed == SPEED_AUTO_NEG &&
 		    (CHIP_IS_E1x(bp) ||
-		     CHIP_IS_E2(bp)))
+		     CHIP_IS_E2(bp))) {
 			bnx2x_set_parallel_detection(phy, params);
 			if (params->phy[INT_PHY].config_init)
 				params->phy[INT_PHY].config_init(phy,
 								 params,
 								 vars);
+		}
 	}
 
 	/* Init external phy*/

^ permalink raw reply related

* Re: [PATCH v2 net-next] pkt_sched: fq: Fair Queue packet scheduler
From: Jason Wang @ 2013-09-05  3:43 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: David Miller, netdev, Yuchung Cheng, Neal Cardwell,
	Michael S. Tsirkin
In-Reply-To: <1378342226.11205.1.camel@edumazet-glaptop>

On 09/05/2013 08:50 AM, Eric Dumazet wrote:
> On Wed, 2013-09-04 at 04:27 -0700, Eric Dumazet wrote:
>> On Wed, 2013-09-04 at 03:30 -0700, Eric Dumazet wrote:
>>> On Wed, 2013-09-04 at 14:30 +0800, Jason Wang wrote:
>>>
>>>>> And tcpdump would certainly help ;)
>>>> See attachment.
>>>>
>>> Nothing obvious on tcpdump (only that lot of frames are missing)
>>>
>>> 1) Are you capturing part of the payload only (like tcpdump -s 128)
>>>
>>> 2) What is the setup.
>>>
>>> 3) tc -s -d qdisc
>> If you use FQ in the guest, then it could be that high resolution timers
>> have high latency ?
>>
>> So FQ arms short timers, but effective duration could be much longer.
>>
>> Here I get a smooth latency of up to ~3 us
>>
>> lpq83:~# ./netperf -H lpq84 ; ./tc -s -d qd ; dmesg | tail -n1
>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lpq84.prod.google.com () 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.00    9410.82   
>> qdisc fq 8005: dev eth0 root refcnt 32 limit 10000p flow_limit 100p buckets 1024 quantum 3028 initial_quantum 15140 
>>  Sent 50545633991 bytes 33385894 pkt (dropped 0, overlimits 0 requeues 19) 
>>  rate 9258Mbit 764335pps backlog 0b 0p requeues 19 
>>   117 flow, 115 inactive, 0 throttled
>>   0 gc, 0 highprio, 0 retrans, 96861 throttled, 0 flows_plimit
>> [  572.551664] latency = 3035 ns
>>
>>
>> What do you get with this debugging patch ?
>>
>> diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
>> index 32ad015..c1312a0 100644
>> --- a/net/sched/sch_fq.c
>> +++ b/net/sched/sch_fq.c
>> @@ -103,6 +103,7 @@ struct fq_sched_data {
>>  	u64		stat_internal_packets;
>>  	u64		stat_tcp_retrans;
>>  	u64		stat_throttled;
>> +	s64		slatency;
>>  	u64		stat_flows_plimit;
>>  	u64		stat_pkts_too_long;
>>  	u64		stat_allocation_errors;
>> @@ -393,6 +394,7 @@ static int fq_enqueue(struct sk_buff *skb, struct Qdisc *sch)
>>  static void fq_check_throttled(struct fq_sched_data *q, u64 now)
>>  {
>>  	struct rb_node *p;
>> +	bool first = true;
>>  
>>  	if (q->time_next_delayed_flow > now)
>>  		return;
>> @@ -405,6 +407,13 @@ static void fq_check_throttled(struct fq_sched_data *q, u64 now)
>>  			q->time_next_delayed_flow = f->time_next_packet;
>>  			break;
>>  		}
>> +		if (first) {
>> +			s64 delay = now - f->time_next_packet;
>> +
>> +			first = false;
>> +			delay -= q->slatency >> 3;
>> +			q->slatency += delay;
>> +		}
>>  		rb_erase(p, &q->delayed);
>>  		q->throttled_flows--;
>>  		fq_flow_add_tail(&q->old_flows, f);
>> @@ -711,6 +720,7 @@ static int fq_dump(struct Qdisc *sch, struct sk_buff *skb)
>>  	if (opts == NULL)
>>  		goto nla_put_failure;
>>  
>> +	pr_err("latency = %lld ns\n", q->slatency >> 3);
>>  	if (nla_put_u32(skb, TCA_FQ_PLIMIT, sch->limit) ||
>>  	    nla_put_u32(skb, TCA_FQ_FLOW_PLIMIT, q->flow_plimit) ||
>>  	    nla_put_u32(skb, TCA_FQ_QUANTUM, q->quantum) ||
>>
>
> BTW what is your HZ value ?

Guest HZ is 1000.
>
> We have a problem in TCP stack, because srtt is in HZ units.
>
> Before we change to us units, I guess tcp_update_pacing_rate() should be
> changed a bit if HZ=250
>
>

^ permalink raw reply

* Re: [PATCH v2 net-next] pkt_sched: fq: Fair Queue packet scheduler
From: Eric Dumazet @ 2013-09-05  3:41 UTC (permalink / raw)
  To: Jason Wang
  Cc: David Miller, netdev, Yuchung Cheng, Neal Cardwell,
	Michael S. Tsirkin
In-Reply-To: <5227F57D.7030709@redhat.com>

On Thu, 2013-09-05 at 11:07 +0800, Jason Wang wrote:

> tc -s -d qdisc
> qdisc fq 8001: dev eth0 root refcnt 2 [Unknown qdisc, optlen=64]
>  Sent 6680760347 bytes 4431855 pkt (dropped 0, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
> 
> btw, is the fq support for tc merged into iproute2? Looks like I can't
> find them.

Yep its there on net-next-3.11 branch

# git branch -a
  master
* net-next-3.11
  remotes/origin/HEAD -> origin/master
  remotes/origin/iproute-3.5.1
  remotes/origin/master
  remotes/origin/net-next-3.11

# cat .git/config 
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master
[branch "net-next-3.11"]
	remote = origin
	merge = refs/heads/net-next-3.11

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox