* Re: [PATCH net v2] net: smc91x: Fix build without gpiolib
From: David Miller @ 2014-12-12 16:30 UTC (permalink / raw)
To: tklauser; +Cc: tony, nico, netdev
In-Reply-To: <20141212162746.GJ16916@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Fri, 12 Dec 2014 17:27:46 +0100
> GPIO is not needed in all configurations of the chip, they are optional.
> That's why I was going for the ugly #ifdef solution.
>
> It seems that there are stubs for the functions in question in
> linux/gpio/consumer.h already as Tony suggested. Thus, adding an
> #include <linux/gpio/consumer.h> to the driver should be enough. I'll
> send an updated patch.
So for the "configurations" that need it, how does the user figure out
that GPIO is needed?
In my opinion, if the code blocks enabling the configurations that
need this are enabled, so should GPIO be depended upon.
I think, at a minimum, when CONFIG_OF is enabled smsc91x should
require GPIO.
^ permalink raw reply
* Re: [PATCH net v2] net: smc91x: Fix build without gpiolib
From: Tobias Klauser @ 2014-12-12 16:27 UTC (permalink / raw)
To: David Miller; +Cc: tony, nico, netdev
In-Reply-To: <20141212.112119.1395396406830853805.davem@davemloft.net>
On 2014-12-12 at 17:21:19 +0100, David Miller <davem@davemloft.net> wrote:
> From: Tony Lindgren <tony@atomide.com>
> Date: Fri, 12 Dec 2014 08:11:00 -0800
>
> > * Tobias Klauser <tklauser@distanz.ch> [141212 08:09]:
> >> If GPIOLIB=n the following build errors occur:
> >>
> >> drivers/net/ethernet/smsc/smc91x.c: In function 'try_toggle_control_gpio':
> >> drivers/net/ethernet/smsc/smc91x.c:2204:2: error: implicit declaration of function 'devm_gpiod_get_index' [-Werror=implicit-function-declaration]
> >> drivers/net/ethernet/smsc/smc91x.c:2204:7: warning: assignment makes pointer from integer without a cast [enabled by default]
> >> drivers/net/ethernet/smsc/smc91x.c:2213:2: error: implicit declaration of function 'gpiod_direction_output' [-Werror=implicit-function-declaration]
> >> drivers/net/ethernet/smsc/smc91x.c:2216:3: error: implicit declaration of function 'devm_gpiod_put' [-Werror=implicit-function-declaration]
> >> drivers/net/ethernet/smsc/smc91x.c:2222:2: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration]
> >>
> >> Since the toggling of the GPIOs is an optional feature, define
> >> try_toggle_control_gpio only if GPIOLIB is enabled.
> >
> > Oops sorry about that, I guess my systems have it all selected so
> > randconfig builds did not expose it.
> >
> > Would it make sense to add the missing gpio stub into
> > include/linux/gpio/consumer.h instead?
>
> I really don't like these kinds of things at all.
>
> If GPIO is required to fully program the hardware properly,
> the smc91x driver should have it as a dependency.
GPIO is not needed in all configurations of the chip, they are optional.
That's why I was going for the ugly #ifdef solution.
It seems that there are stubs for the functions in question in
linux/gpio/consumer.h already as Tony suggested. Thus, adding an
#include <linux/gpio/consumer.h> to the driver should be enough. I'll
send an updated patch.
^ permalink raw reply
* Re: [PATCH net] net: ethernet: davicom: Allow to select DM9000 for nios2
From: David Miller @ 2014-12-12 16:26 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1418376071-28709-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Fri, 12 Dec 2014 10:21:11 +0100
> This chip is present on older revisions of the DE2 development kit.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net] net: ethernet: smsc: Allow to select SMC91X for nios2
From: David Miller @ 2014-12-12 16:26 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1418376068-28649-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Fri, 12 Dec 2014 10:21:08 +0100
> This chip is present on the Nios2 Development Kit 2C35.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net] cxgb4: Add support for QSA modules
From: David Miller @ 2014-12-12 16:24 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, anish, nirranjan
In-Reply-To: <1418366277-13317-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Fri, 12 Dec 2014 12:07:57 +0530
> Firmware 1.12.25.0 added support for QSA module, adding the driver code for it.
> Also fixes some ethtool get settings for other module types.
>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v10 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i
From: David Miller @ 2014-12-12 16:22 UTC (permalink / raw)
To: kxie; +Cc: linux-scsi, netdev, hariprasad, anish, hch, James.Bottomley,
michaelc
In-Reply-To: <201412120313.sBC3DQhF028321@localhost6.localdomain6>
From: Karen Xie <kxie@chelsio.com>
Date: Thu, 11 Dec 2014 19:13:26 -0800
> This patch set fixes cxgb4i's tx credit calculation and adds handling of
> additional rx message and negative advice types. It also removes the duplicate
> code in cxgb4i to set the outgoing queues of a packet.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net v2] net: smc91x: Fix build without gpiolib
From: David Miller @ 2014-12-12 16:21 UTC (permalink / raw)
To: tony; +Cc: tklauser, nico, netdev
In-Reply-To: <20141212161100.GH2950@atomide.com>
From: Tony Lindgren <tony@atomide.com>
Date: Fri, 12 Dec 2014 08:11:00 -0800
> * Tobias Klauser <tklauser@distanz.ch> [141212 08:09]:
>> If GPIOLIB=n the following build errors occur:
>>
>> drivers/net/ethernet/smsc/smc91x.c: In function 'try_toggle_control_gpio':
>> drivers/net/ethernet/smsc/smc91x.c:2204:2: error: implicit declaration of function 'devm_gpiod_get_index' [-Werror=implicit-function-declaration]
>> drivers/net/ethernet/smsc/smc91x.c:2204:7: warning: assignment makes pointer from integer without a cast [enabled by default]
>> drivers/net/ethernet/smsc/smc91x.c:2213:2: error: implicit declaration of function 'gpiod_direction_output' [-Werror=implicit-function-declaration]
>> drivers/net/ethernet/smsc/smc91x.c:2216:3: error: implicit declaration of function 'devm_gpiod_put' [-Werror=implicit-function-declaration]
>> drivers/net/ethernet/smsc/smc91x.c:2222:2: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration]
>>
>> Since the toggling of the GPIOs is an optional feature, define
>> try_toggle_control_gpio only if GPIOLIB is enabled.
>
> Oops sorry about that, I guess my systems have it all selected so
> randconfig builds did not expose it.
>
> Would it make sense to add the missing gpio stub into
> include/linux/gpio/consumer.h instead?
I really don't like these kinds of things at all.
If GPIO is required to fully program the hardware properly,
the smc91x driver should have it as a dependency.
^ permalink raw reply
* Re: [PATCH net v2] net: smc91x: Fix build without gpiolib
From: Tony Lindgren @ 2014-12-12 16:11 UTC (permalink / raw)
To: Tobias Klauser; +Cc: Nicolas Pitre, David S. Miller, netdev
In-Reply-To: <1418400429-6680-1-git-send-email-tklauser@distanz.ch>
* Tobias Klauser <tklauser@distanz.ch> [141212 08:09]:
> If GPIOLIB=n the following build errors occur:
>
> drivers/net/ethernet/smsc/smc91x.c: In function 'try_toggle_control_gpio':
> drivers/net/ethernet/smsc/smc91x.c:2204:2: error: implicit declaration of function 'devm_gpiod_get_index' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/smsc/smc91x.c:2204:7: warning: assignment makes pointer from integer without a cast [enabled by default]
> drivers/net/ethernet/smsc/smc91x.c:2213:2: error: implicit declaration of function 'gpiod_direction_output' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/smsc/smc91x.c:2216:3: error: implicit declaration of function 'devm_gpiod_put' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/smsc/smc91x.c:2222:2: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration]
>
> Since the toggling of the GPIOs is an optional feature, define
> try_toggle_control_gpio only if GPIOLIB is enabled.
Oops sorry about that, I guess my systems have it all selected so
randconfig builds did not expose it.
Would it make sense to add the missing gpio stub into
include/linux/gpio/consumer.h instead?
Regards,
Tony
> Fixes: 7d2911c4381 ("net: smc91x: Fix gpios for device tree based booting")
> Cc: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> ---
> drivers/net/ethernet/smsc/smc91x.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
> index 6cc3cf6..050bcb6 100644
> --- a/drivers/net/ethernet/smsc/smc91x.c
> +++ b/drivers/net/ethernet/smsc/smc91x.c
> @@ -2193,6 +2193,7 @@ MODULE_DEVICE_TABLE(of, smc91x_match);
> /**
> * of_try_set_control_gpio - configure a gpio if it exists
> */
> +#ifdef CONFIG_GPIOLIB
> static int try_toggle_control_gpio(struct device *dev,
> struct gpio_desc **desc,
> const char *name, int index,
> @@ -2224,7 +2225,16 @@ static int try_toggle_control_gpio(struct device *dev,
>
> return 0;
> }
> -#endif
> +#else
> +static int try_toggle_control_gpio(struct device *dev,
> + struct gpio_desc **desc,
> + const char *name, int index,
> + int value, unsigned int nsdelay)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_GPIOLIB */
> +#endif /* CONFIG_OF */
>
> /*
> * smc_init(void)
> --
> 2.2.0
>
>
^ permalink raw reply
* Re: [net PATCH] fib_trie: Fix trie balancing issue if new node pushes down existing node
From: Alexander Duyck @ 2014-12-12 16:09 UTC (permalink / raw)
To: David Miller, alexander.h.duyck; +Cc: netdev
In-Reply-To: <20141212.105425.2023800747122061277.davem@davemloft.net>
On 12/12/2014 07:54 AM, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 11 Dec 2014 21:32:16 -0500 (EST)
>
>> From: Alexander Duyck <alexander.h.duyck@redhat.com>
>> Date: Wed, 10 Dec 2014 21:49:22 -0800
>>
>>> This patch addresses an issue with the level compression of the fib_trie.
>>> Specifically in the case of adding a new leaf that triggers a new node to
>>> be added that takes the place of the old node. The result is a trie where
>>> the 1 child tnode is on one side and one leaf is on the other which gives
>>> you a very deep trie. Below is the script I used to generate a trie on
>>> dummy0 with a 10.X.X.X family of addresses.
>> ...
>>> What this fix does is start the rebalance at the newly created tnode
>>> instead of at the parent tnode. This way if there is a gap between the
>>> parent and the new node it doesn't prevent the new tnode from being
>>> coalesced with any pre-existing nodes that may have been pushed into one
>>> of the new nodes child branches.
>>>
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
>> One has to be mindful with this code that what it's doing now might
>> be intentional. For example, it might be doing things this way
>> on purpose in order to minimize rebalancing during route flaps.
>>
>> Barring anything like that, I think your change is fine.
> Alex, in case it isn't clear, I'm hoping that you might have some
> thoughts on this aspect of your changes. :)
Route flaps should at most trigger an inflate without a deflate due to
the way the resize logic works. If this occurs often it would be useful
since then there would already be space in the tree for the next time
around.
- Alex
^ permalink raw reply
* [PATCH net v2] net: smc91x: Fix build without gpiolib
From: Tobias Klauser @ 2014-12-12 16:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: David S. Miller, Tony Lindgren, netdev
If GPIOLIB=n the following build errors occur:
drivers/net/ethernet/smsc/smc91x.c: In function 'try_toggle_control_gpio':
drivers/net/ethernet/smsc/smc91x.c:2204:2: error: implicit declaration of function 'devm_gpiod_get_index' [-Werror=implicit-function-declaration]
drivers/net/ethernet/smsc/smc91x.c:2204:7: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/net/ethernet/smsc/smc91x.c:2213:2: error: implicit declaration of function 'gpiod_direction_output' [-Werror=implicit-function-declaration]
drivers/net/ethernet/smsc/smc91x.c:2216:3: error: implicit declaration of function 'devm_gpiod_put' [-Werror=implicit-function-declaration]
drivers/net/ethernet/smsc/smc91x.c:2222:2: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration]
Since the toggling of the GPIOs is an optional feature, define
try_toggle_control_gpio only if GPIOLIB is enabled.
Fixes: 7d2911c4381 ("net: smc91x: Fix gpios for device tree based booting")
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ethernet/smsc/smc91x.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 6cc3cf6..050bcb6 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -2193,6 +2193,7 @@ MODULE_DEVICE_TABLE(of, smc91x_match);
/**
* of_try_set_control_gpio - configure a gpio if it exists
*/
+#ifdef CONFIG_GPIOLIB
static int try_toggle_control_gpio(struct device *dev,
struct gpio_desc **desc,
const char *name, int index,
@@ -2224,7 +2225,16 @@ static int try_toggle_control_gpio(struct device *dev,
return 0;
}
-#endif
+#else
+static int try_toggle_control_gpio(struct device *dev,
+ struct gpio_desc **desc,
+ const char *name, int index,
+ int value, unsigned int nsdelay)
+{
+ return 0;
+}
+#endif /* CONFIG_GPIOLIB */
+#endif /* CONFIG_OF */
/*
* smc_init(void)
--
2.2.0
^ permalink raw reply related
* Re: [PATCH net] net: smc91x: Fix build without gpiolib
From: Tobias Klauser @ 2014-12-12 16:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: David S. Miller, Tony Lindgren, netdev
In-Reply-To: <1418400022-6264-1-git-send-email-tklauser@distanz.ch>
On 2014-12-12 at 17:00:22 +0100, Tobias Klauser <tklauser@distanz.ch> wrote:
> If GPIOLIB=n the following build error occurs:
Sorry, I forgot to paste the following error message here:
drivers/net/ethernet/smsc/smc91x.c: In function 'try_toggle_control_gpio':
drivers/net/ethernet/smsc/smc91x.c:2204:2: error: implicit declaration of function 'devm_gpiod_get_index' [-Werror=implicit-function-declaration]
drivers/net/ethernet/smsc/smc91x.c:2204:7: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/net/ethernet/smsc/smc91x.c:2213:2: error: implicit declaration of function 'gpiod_direction_output' [-Werror=implicit-function-declaration]
drivers/net/ethernet/smsc/smc91x.c:2216:3: error: implicit declaration of function 'devm_gpiod_put' [-Werror=implicit-function-declaration]
drivers/net/ethernet/smsc/smc91x.c:2222:2: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration]
I'll send an updated patch. Please disregard this one.
^ permalink raw reply
* Re: randconfig build error with next-20141210, in drivers/net/ethernet/broadcom/genet
From: David Miller @ 2014-12-12 16:02 UTC (permalink / raw)
To: f.fainelli; +Cc: jim.epost, sfr, linux-next, linux-kernel, netdev
In-Reply-To: <548A786D.2060201@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 11 Dec 2014 21:09:01 -0800
> Le 11/12/2014 11:22, David Miller a écrit :
>> From: Jim Davis <jim.epost@gmail.com> Date: Wed, 10 Dec 2014
>> 09:10:45 -0700
>>
>>> Building with the attached random configuration file,
>>>
>>> ERROR: "fixed_phy_register"
>>> [drivers/net/ethernet/broadcom/genet/genet.ko] undefined!
>>
>> Florian, I don't understand why FIXED_PHY is only selected in
>> Kconfig if the driver is statically built into the kernel.
>>
>> That makes no sense at all, you should need that module regardless
>> of how the driver itself is enabled.
>
> AFAIR this was introduced to silence a warning you reported:
>
> "I think you need to work on the Kconfig dependencies a little bit more.
> I have BCMGENET specified as modular, which absolutely should work. Yet
> Kconfig complains.
>
> warning: (BCMGENET) selects FIXED_PHY which has unmet direct
> dependencies (NETDEVICES && PHYLIB=y)"
>
> but I agree, this makes no sense, we should select FIXED_PHY
> unconditionnally, will send you patches tomorrow to fix that.
What's really perplexing is that FIXED_PHY is only enable'able
when PHYLIB=y. I think that's the core of the problems here.
All of these drivers shouldn't lose fixed phy support simply
because they, or PHYLIB itself, is built modular.
^ permalink raw reply
* Re: [PATCH] net: phy: export fixed_phy_register()
From: David Miller @ 2014-12-12 16:01 UTC (permalink / raw)
To: msalter; +Cc: f.fainelli, netdev, linux-kernel
In-Reply-To: <1418357006-2450-1-git-send-email-msalter@redhat.com>
From: Mark Salter <msalter@redhat.com>
Date: Thu, 11 Dec 2014 23:03:26 -0500
> When building the bcmgenet driver as module, I get:
>
> ERROR: "fixed_phy_register" [drivers/net/ethernet/broadcom/genet/genet.ko] undefined!
>
> commit b0ba512e225d72 ("net: bcmgenet: enable driver to work without device
> tree") which added a call to fixed_phy_register. But fixed_phy_register
> needs to be exported if used from a module.
>
> Signed-off-by: Mark Salter <msalter@redhat.com>
APplied.
^ permalink raw reply
* Re: [PATCH net-next] vlan: Add ability to always enable TSO/UFO
From: David Miller @ 2014-12-12 16:01 UTC (permalink / raw)
To: makita.toshiaki; +Cc: kaber, netdev
In-Reply-To: <1418179394-4470-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date: Wed, 10 Dec 2014 11:43:13 +0900
> Since the real device can segment packets by software, a vlan device
> can set TSO/UFO even when the real device doesn't have those features.
> Unlike GSO, this allows packets to be segmented after Qdisc.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Applied.
^ permalink raw reply
* Re: [net PATCH] fib_trie: Fix trie balancing issue if new node pushes down existing node
From: David Miller @ 2014-12-12 16:00 UTC (permalink / raw)
To: alexander.duyck; +Cc: alexander.h.duyck, netdev
In-Reply-To: <548B0FD6.8040105@gmail.com>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Fri, 12 Dec 2014 07:55:02 -0800
> On 12/11/2014 06:32 PM, David Miller wrote:
>> From: Alexander Duyck <alexander.h.duyck@redhat.com>
>> Date: Wed, 10 Dec 2014 21:49:22 -0800
>>
>>> This patch addresses an issue with the level compression of the fib_trie.
>>> Specifically in the case of adding a new leaf that triggers a new node to
>>> be added that takes the place of the old node. The result is a trie where
>>> the 1 child tnode is on one side and one leaf is on the other which gives
>>> you a very deep trie. Below is the script I used to generate a trie on
>>> dummy0 with a 10.X.X.X family of addresses.
>> ...
>>> What this fix does is start the rebalance at the newly created tnode
>>> instead of at the parent tnode. This way if there is a gap between the
>>> parent and the new node it doesn't prevent the new tnode from being
>>> coalesced with any pre-existing nodes that may have been pushed into one
>>> of the new nodes child branches.
>>>
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
>> One has to be mindful with this code that what it's doing now might
>> be intentional. For example, it might be doing things this way
>> on purpose in order to minimize rebalancing during route flaps.
>>
>> Barring anything like that, I think your change is fine.
>
> I'm fairly certain that this isn't intentional. If we replace a NULL
> pointer in an existing tnode then we rebalance starting at that tnode,
> it is only when there is no room in the trie and we have to add a new
> tnode that the issue occurs where we rebalance at the parent and not the
> tnode that the leaf was added to.
Ok, thanks for taking the time to explain this, I'm now convinced :)
Applied, thanks again.
^ permalink raw reply
* [PATCH net] net: smc91x: Fix build without gpiolib
From: Tobias Klauser @ 2014-12-12 16:00 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: David S. Miller, Tony Lindgren, netdev
If GPIOLIB=n the following build error occurs:
Since the toggling of the GPIOs is an optional feature, define
try_toggle_control_gpio only if GPIOLIB is enabled.
Fixes: 7d2911c4381 ("net: smc91x: Fix gpios for device tree based booting")
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ethernet/smsc/smc91x.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 6cc3cf6..050bcb6 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -2193,6 +2193,7 @@ MODULE_DEVICE_TABLE(of, smc91x_match);
/**
* of_try_set_control_gpio - configure a gpio if it exists
*/
+#ifdef CONFIG_GPIOLIB
static int try_toggle_control_gpio(struct device *dev,
struct gpio_desc **desc,
const char *name, int index,
@@ -2224,7 +2225,16 @@ static int try_toggle_control_gpio(struct device *dev,
return 0;
}
-#endif
+#else
+static int try_toggle_control_gpio(struct device *dev,
+ struct gpio_desc **desc,
+ const char *name, int index,
+ int value, unsigned int nsdelay)
+{
+ return 0;
+}
+#endif /* CONFIG_GPIOLIB */
+#endif /* CONFIG_OF */
/*
* smc_init(void)
--
2.2.0
^ permalink raw reply related
* Re: [net PATCH] fib_trie: Fix trie balancing issue if new node pushes down existing node
From: Alexander Duyck @ 2014-12-12 15:55 UTC (permalink / raw)
To: David Miller, alexander.h.duyck; +Cc: netdev
In-Reply-To: <20141211.213216.1630491264342423219.davem@davemloft.net>
On 12/11/2014 06:32 PM, David Miller wrote:
> From: Alexander Duyck <alexander.h.duyck@redhat.com>
> Date: Wed, 10 Dec 2014 21:49:22 -0800
>
>> This patch addresses an issue with the level compression of the fib_trie.
>> Specifically in the case of adding a new leaf that triggers a new node to
>> be added that takes the place of the old node. The result is a trie where
>> the 1 child tnode is on one side and one leaf is on the other which gives
>> you a very deep trie. Below is the script I used to generate a trie on
>> dummy0 with a 10.X.X.X family of addresses.
> ...
>> What this fix does is start the rebalance at the newly created tnode
>> instead of at the parent tnode. This way if there is a gap between the
>> parent and the new node it doesn't prevent the new tnode from being
>> coalesced with any pre-existing nodes that may have been pushed into one
>> of the new nodes child branches.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
> One has to be mindful with this code that what it's doing now might
> be intentional. For example, it might be doing things this way
> on purpose in order to minimize rebalancing during route flaps.
>
> Barring anything like that, I think your change is fine.
I'm fairly certain that this isn't intentional. If we replace a NULL
pointer in an existing tnode then we rebalance starting at that tnode,
it is only when there is no room in the trie and we have to add a new
tnode that the issue occurs where we rebalance at the parent and not the
tnode that the leaf was added to.
- Alex
^ permalink raw reply
* Re: [net PATCH] fib_trie: Fix trie balancing issue if new node pushes down existing node
From: David Miller @ 2014-12-12 15:54 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev
In-Reply-To: <20141211.213216.1630491264342423219.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 11 Dec 2014 21:32:16 -0500 (EST)
> From: Alexander Duyck <alexander.h.duyck@redhat.com>
> Date: Wed, 10 Dec 2014 21:49:22 -0800
>
>> This patch addresses an issue with the level compression of the fib_trie.
>> Specifically in the case of adding a new leaf that triggers a new node to
>> be added that takes the place of the old node. The result is a trie where
>> the 1 child tnode is on one side and one leaf is on the other which gives
>> you a very deep trie. Below is the script I used to generate a trie on
>> dummy0 with a 10.X.X.X family of addresses.
> ...
>> What this fix does is start the rebalance at the newly created tnode
>> instead of at the parent tnode. This way if there is a gap between the
>> parent and the new node it doesn't prevent the new tnode from being
>> coalesced with any pre-existing nodes that may have been pushed into one
>> of the new nodes child branches.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
>
> One has to be mindful with this code that what it's doing now might
> be intentional. For example, it might be doing things this way
> on purpose in order to minimize rebalancing during route flaps.
>
> Barring anything like that, I think your change is fine.
Alex, in case it isn't clear, I'm hoping that you might have some
thoughts on this aspect of your changes. :)
^ permalink raw reply
* Re: [PATCH net-next] Avoid reducing cwnd when ACK+DSACK is received
From: Neal Cardwell @ 2014-12-12 15:54 UTC (permalink / raw)
To: Sébastien Barré
Cc: David Miller, Netdev, Gregory Detal, Nandita Dukkipati,
Yuchung Cheng
In-Reply-To: <1418327890-368-1-git-send-email-sebastien.barre@uclouvain.be>
On Thu, Dec 11, 2014 at 2:58 PM, Sébastien Barré
<sebastien.barre@uclouvain.be> wrote:
> When the peer has delayed ack enabled, it may reply to a probe with an
> ACK+D-SACK, with ack value set to tlp_high_seq. In the current code,
> such ACK+DSACK will be missed and only at next, higher ack will the TLP
> episode be considered done. Since the DSACK is not present anymore,
> this will cost a cwnd reduction.
>
> This patch ensures that this scenario does not cause a cwnd reduction, since
> receiving an ACK+DSACK indicates that both the initial segment and the probe
> have been received by the peer.
>
> Cc: Gregory Detal <gregory.detal@uclouvain.be>
> Cc: Nandita Dukkipati <nanditad@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
BTW, I like this idea, and I'll test it.
Two suggestions for the next iteration:
(1) for TCP patch style, I'd suggest a commit first-line like:
tcp: avoid reducing cwnd when ACK+DSACK is received
(2) Your patch is essentially a reworking of the is_tlp_dupack
computation. So rather than splitting the logic between the
is_tlp_dupack computation and the new expression inside the if
condition, I'd suggest moving and centralizing all the logic in the if
condition. There is no real need for the is_tlp_dupack variable.
neal
^ permalink raw reply
* Re: [PATCH v2 0/6] net-PPP: Deletion of a few unnecessary checks
From: David Miller @ 2014-12-12 15:51 UTC (permalink / raw)
To: elfring
Cc: sergei.shtylyov, paulus, linux-ppp, netdev, eric.dumazet,
linux-kernel, kernel-janitors, julia.lawall
In-Reply-To: <548B0A29.8050503@users.sourceforge.net>
You are asking me to invest a lot of time for a very trivial
set of changes.
Why don't you just integrate the feedback you were given and
resubmit your patch series, just like any other developer would?
^ permalink raw reply
* Re: [PATCH v2 0/6] net-PPP: Deletion of a few unnecessary checks
From: SF Markus Elfring @ 2014-12-12 15:30 UTC (permalink / raw)
To: David Miller
Cc: Sergei Shtylyov, Paul Mackerras, linux-ppp, netdev, Eric Dumazet,
linux-kernel, kernel-janitors, Julia Lawall
In-Reply-To: <20141212.092950.1840808214143867233.davem@davemloft.net>
> I gave you very concrete feedback, I said exactly that I don't want
> error pointers left in data structure members.
I find that your critique affects the proposed update steps four to six,
doesn't it?
Are the other steps acceptable in principle?
> I cannot describe my requirements any more precisely than that.
I hope that a bit more constructive suggestions will be contributed by
involved
software developers around the affected source code. Now it seems
that a small code clean-up becomes a more challenging development task.
How do you prefer to redesign corresponding data structures eventually?
Regards,
Markus
^ permalink raw reply
* NetDev 0.1 Attendee clarification [was: Netdev 0.1 Call for Proposals]
From: Richard Guy Briggs @ 2014-12-12 15:09 UTC (permalink / raw)
To: netdev, linux-wireless, lwn, netdev01, lartc, netfilter,
netfilter-devel
In-Reply-To: <20141203022815.GM4612@toccata2.tricolour.ca>
On 14/12/02, Richard Guy Briggs wrote:
> Netdev 0.1 Call for Proposals
> -----------------------------
>
> Netdev 0.1 (year 0, conference 1) is a community-driven conference
> geared towards Linux netheads. Linux kernel networking and user
> space utilization of the interfaces to the Linux kernel networking
> subsystem are the focus.
Hello fellow Linux NetHeads, sorry for the noise:
There seems to have been some questions about the intended audience for this
conference.
The 50/50 by-invitation/submission slots are for the *presenters* of the talks
and not for the audience of attendees. *Anyone* with an interest in Linux
networking is welcome to attend this conference.
We're very sorry for the confusion and welcome you to join us.
Cheers.
> There are 4 phases/formats to Netdev 0.1
>
> 1) Workshops (day 1)
>
> The workshop format is inspired by Netconf and the wireless
> mini-summits, with workshops being centered around existing
> networking subsystems. workshops are intended to be an extension of
> the mailing list in the sense that many times previous
> discussions from the mailing list (or that could otherwise have
> happened there) are taken to the round-table to simplify the
> decision-making process.
>
> The networking subsystem maintainer(s) should at least prepare a
> list of agenda items well before the workshop takes place to allow
> participants to come prepared; this makes the discussions most productive.
> Sometimes brain-storming sessions will also be appropriate where
> being prepared is less important, for example for discussions
> around new user requirements this can be very valuable.
>
> At the workshop meeting itself discussions prevail and notes are
> later sent back to the mailing list; presentations are typically
> - at the discretion of the chairs - only used where needed to
> clarify a problem statement for discussion.
>
> The sitting format is round-table.
>
> 2) BOFs (day 1)
>
> BOFs are sessions with a potential to become a workshop in a future
> Netdev conference. The lifetime of a BOF may be only one or two
> Netdev conference gatherings. We discourage perpetual BOFs.
> BoFs don't need to have an existing networking subsystem or mailing list.
> BOFs also don't need to strive to be upgraded to be a Workshop
> in the future. Their longevity could only be one conference.
> The sitting format could vary and be either lecture or round table format
> depending on the proposal.
>
> 3) Tutorials (day 2)
>
> Tutorials are generally about 2 hours long (or more at the discretion
> of the proposal).
> Tutorials are educational in nature and are presented in a classroom
> format with a specific educational outcome for the attendees.
>
> 4) Paper proposals (days 3 and 4)
>
> These are classical conference paper + presentations.
> Presentations are 30 minutes long with an additional 15 minutes for Q&A
> presented in a lecture format.
> We will require paper submissions for these sessions. The committee
> believes that a paper submission raises the quality of the presentations
> and makes it easier to build on presented ideas in the future.
>
> The Netdev conference this year is structured to be 50% by-invitation
> and 50% submission. We are making sure that we reach out to speakers
> who have interesting relevant topics because we recognize most of
> these folks would typically not be submitting papers to a conference.
> The invitation will be made by the technical committee to the individual
> speakers for workshop, paper and tutorial sessions.
Clarification is that the presenters will be split 50/50 invitation/submission
and that regular attendance is open to anyone and we will welcome anyone to
join the conference audience.
> This call for papers is for the 50% submission portion of the
> conference for paper submissions, tutorials and workshops.
> We *highly discourage* submission of recycled talks.
>
> Current technical focus topics include:
> - wireless
> - performance analysis, debugging and improvement
> - networking hardware and offload
> - netfilter
> - traffic control
> - different networking layers (L2/3, etc)
> - Internet of things
> - security
> - additional topics can be suggested
>
> Unlike other conferences, we are going to try and accommodate as many
> submissions as possible - but please stay within the relevant topic focus
> and tie to Linux networking to make it easier for the technical committee
> to provide quick feedback. In order to give a talk you must be
> registered. If your proposal is accepted you will not be charged
> a conference fee or your conference fee will be refunded to you
> when your talk gets accepted.
>
> We expect minimum of 2 parallel tracks but likely more depending on the
> (quantity of submissions) in all phases i.e during tutorials,
> workshops and main talks.
>
> Why you should submit a proposal
> ---------------------------------
> If you yearn for the old community tech driven conferences where
> you mingle with fellow geeks (only these would be Linux networking
> geeks) then this would be it. There will be no marketing flashy
> openings. There will just be a pure feed of Linux networking.
> Netdev 0.1 will be held back to back with Netconf 2015, the
> by-invite Linux kernel networking workshop
> (http://vger.kernel.org/netconf2015.html).
> So gurus of all sorts will be there mingling and giving talks.
> While there will be heavy Linux kernel influence we expect a lot
> of user space presence as well.
>
> How to submit a proposal
> ------------------------
> Send email to netdev01@lists.netfilter.org with a paragraph or
> two of your proposal.
> For paper proposals, if your submission is accepted we will provide
> you a template to use.
> A minimum of two pages is needed so as to to allow people to skip the
> burden of writing a large paper. The maximum page limit is 10 pages.
>
> Location:
> ---------
> Downtown Ottawa, Canada
> www.netdev01.org
>
> Important Dates:
> ----------------
> December 02, 2014 Call for Papers opens
> December 10, 2014 Registration opens
> January 10, 2015 Call for sessions deadline
> January 20, 2015 Conference schedule announced
> February 14-17, 2015 Conference days
>
> Please register as soon as registration opens up on December 10.
> Registering helps us plan properly for numbers of attendees,
> ensuring venue sizes and supplies are appropriate without
> wasting resources.
>
>
>
> slainte mhath, RGB
slainte mhath, RGB
--
Richard Guy Briggs -- ~\ -- ~\ <hpv.tricolour.ca>
<www.TriColour.ca> -- \___ o \@ @ Ride yer bike!
Ottawa, ON, CANADA -- Lo_>__M__\\/\%__\\/\%
Vote! -- <greenparty.ca>_____GTVS6#790__(*)__(*)________(*)(*)_________________
^ permalink raw reply
* Re: tg3 broken in 3.18.0?
From: Jonathan Bither @ 2014-12-12 14:50 UTC (permalink / raw)
To: Marcelo Ricardo Leitner, Nils Holland, netdev
In-Reply-To: <5489CA3C.10803@gmail.com>
Not sure if it helps any, but tg3 works here after a 3.18 upgrade. I'd
be happy to share any information if it would help you out.
[root@www ~]# uname -a
Linux localhost 3.18.0-1.el6.elrepo.i686 #1 SMP Mon Dec 8 10:55:34 EST
2014 i686 i686 i386 GNU/Linux
[root@www ~]# ethtool -i eth0
driver: tg3
version: 3.137
firmware-version: 5704-v3.36, ASFIPMIc v2.37
bus-info: 0000:02:03.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
[root@www ~]# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on
Supports Wake-on: g
Wake-on: g
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
[root@www ~]#
On 12/11/2014 11:45 AM, Marcelo Ricardo Leitner wrote:
> On 10-12-2014 21:06, Nils Holland wrote:
>> Hi everyone,
>>
>> I just upgraded a machine from 3.17.3 to 3.18.0 and noticed that after
>> the upgrade, the machine's network interface (which is a tg3) would no
>> longer run correctly (or, for that matter, run at all). During the
>> upgrade, I didn't change any kernel config options or any other parts
>> of the system.
>
> Same thing here! Thanks for reporting this, Nils.
>
>> Since the machine is remote and I don't have direct access to it, it's
>> kind of hard currently to give more details, but here's what I'm
>> seeing in the logs:
>
> I have access to mine, kudos to secondary NIC.
>
> $ ethtool -i p1p1
> driver: tg3
> version: 3.137
> firmware-version: 5722-v3.13
> bus-info: 0000:02:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: no
>
> $ ethtool p1p1
> Settings for p1p1:
> Supported ports: [ TP ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Advertised pause frame use: Symmetric
> Advertised auto-negotiation: Yes
> Speed: Unknown!
> Duplex: Unknown! (255)
> Port: Twisted Pair
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> MDI-X: Unknown
>
> $ sudo ip link set p1p1 up
> RTNETLINK answers: No such device
>
>> If I see things correctly, there were only two patches affecting tg3
>> between 3.17(.3) and 3.18:
>>
>> 2c7c9ea429ba30fe506747b7da110e2212d8fefa
>> a620a6bc1c94c22d6c312892be1e0ae171523125
>
> I'm running net-next, 395eea6ccf2b253f81b4718ffbcae67d36fe2e69.
> So my diffs would be:
> $ git log v3.17..origin/master --oneline --
> drivers/net/ethernet/broadcom/tg3.c
> 892311f ethtool: Support for configurable RSS hash function
> 60b7379 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> a620a6b tg3: fix ring init when there are more TX than RX channels
> 3964835 tg3: use netdev_rss_key_fill() helper
> 2c7c9ea tg3: Add skb->xmit_more support
>
> Reverting all these, issue continues.
>
> If no one has a better shot, I'll try bissecting later.
>
> Marcelo
>
> --
> 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: [netdev01] registration inconsistency
From: Jamal Hadi Salim @ 2014-12-12 14:45 UTC (permalink / raw)
To: Richard Guy Briggs, Johannes Berg
Cc: netdev01, Brenda Butler, netdev@vger.kernel.org,
Richard Guy Briggs
In-Reply-To: <20141212140108.GU392@toccata2.tricolour.ca>
On 12/12/14 09:01, Richard Guy Briggs wrote:
> I totally missed that as well, but agree it should be clarified with a reply
> and a news item on the web site as well as a change to the wording on the web
> site.
>
Sounds reasonable to me.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined.
From: Jamal Hadi Salim @ 2014-12-12 14:35 UTC (permalink / raw)
To: Hubert Sokolowski; +Cc: Roopa Prabhu, netdev@vger.kernel.org, Vlad Yasevich
In-Reply-To: <4c22a6c452a73b3b77a9a9c8e7f76bcc.squirrel@poczta.wsisiz.edu.pl>
On 12/12/14 08:36, Hubert Sokolowski wrote:
>> On 12/12/14 06:38, Hubert Sokolowski wrote:
>>>> On 12/11/14, 9:06 AM, Hubert Sokolowski wrote:
>>
>>> Please see how the ndo_dflt_fdb_add and del are called:
>>> if (dev->netdev_ops->ndo_fdb_add)
>>> err = dev->netdev_ops->ndo_fdb_add(ndm, tb, dev, addr,
>>> vid,
>>> nlh->nlmsg_flags);
>>> else
>>> err = ndo_dflt_fdb_add(ndm, tb, dev, addr, vid,
>>> nlh->nlmsg_flags);
>>>
>>
>> Semantically add and dump are not the same.
>> Add adds a specific entry.
>> Dump not only dumps the fdb table but also the unicast and multicast
>> addresses.
> this is not true for 3.16 and before. Please see:
> http://lxr.free-electrons.com/source/net/core/rtnetlink.c?v=3.16#L2545
> It lets you fully manage the FDB table by overwriding fdb_add, del and dump
> in the same way.
>
>
>
>>
>>
>>> As it was suggested by Ronen I can modify the patch so the dflt callback
>>> is always called for bridge devices if this is desirable. Either by calling
>>> it when following expression is true:
>>> (dev->priv_flags & IFF_BRIDGE_PORT)
>>> or by modifying br_fdb_dump to call ndo_dflt_fdb_dump.
>>>
>>
>> Are you saying the above is going to work? You need to TEST please.
> yes, it works and it is not a rocket science :). we just need to agree
> on the approach to use.
>
I am happy if this solves wont break
any of the use cases Vlad made me test and make sure work.
When i said "test" - I mean run the testcases outlined in the
commit log; if those work i dont see what the issue is.
cheers,
jamal
^ 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