Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] net: phy: at803x: don't depend on GPIOLIB
From: Sebastian Frias @ 2016-03-18 15:56 UTC (permalink / raw)
  To: Uwe Kleine-König, Daniel Mack
  Cc: David S. Miller, netdev, lkml, mason, Florian Fainelli,
	Mans Rullgard, Fabio Estevam, Martin Blumenstingl, Linus Walleij
In-Reply-To: <20160318125455.GN4292@pengutronix.de>

Hi Uwe, Daniel,

On 03/18/2016 01:54 PM, Uwe Kleine-König wrote:
> [expand cc a bit more]
> 
> Hello,
> 
> On Wed, Mar 16, 2016 at 06:25:59PM +0100, Sebastian Frias wrote:
>> Commit 687908c2b649 ("net: phy: at803x: simplify using
>> devm_gpiod_get_optional and its 4th argument") introduced a dependency
>> on GPIOLIB that was not there before.
>>
>> This commit removes such dependency by checking the return code and
>> comparing it against ENOSYS which is returned when GPIOLIB is not
>> selected.
>>
>> Fixes: 687908c2b649 ("net: phy: at803x: simplify using devm_gpiod_get_optional and its 4th argument")
>>
>> Signed-off-by: Sebastian Frias <sf84@laposte.net>
>> ---
>>  drivers/net/phy/at803x.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
>> index 2174ec9..88b7ff3 100644
>> --- a/drivers/net/phy/at803x.c
>> +++ b/drivers/net/phy/at803x.c
>> @@ -252,7 +252,9 @@ static int at803x_probe(struct phy_device *phydev)
>>  		return -ENOMEM;
>>
>>  	gpiod_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
>> -	if (IS_ERR(gpiod_reset))
>> +	if (PTR_ERR(gpiod_reset) == -ENOSYS)
>> +		gpiod_reset = NULL;
>> +	else if (IS_ERR(gpiod_reset))
> 
> this isn't better either (IMHO it's worse, but maybe this is debatable
> and also depends on your POV).

Well, from the code, the reset hack is only required when the PHY is
ATH8030_PHY_ID, right?
However, such change was introduced by Daniel Mack on commit 13a56b449325.
Hopefully he can chime in and give his opinion on this.

Daniel, while on the subject, I have a question for you:

Change 2b8f2a28eac1 introduced "link_status_notify" callback which is
called systematically on the PHY state machine.
Any reason to make the call systematic as opposed to let say:

	if (phydev->state != old_state) {
		if (phydev->drv->link_change_notify)
			phydev->drv->link_change_notify(phydev);
	}

(it does means that the callback would be called after the state machine
processing though)

> 
> With 687908c2b649 I made kernels without GPIOLIB fail to bind this
> device. I admit this is not maximally nice.

I see, that was not clear from the commit message, sorry.

> 
> Your change makes the driver bind in this case again and then the reset
> gpio isn't handled at all which might result in a later and harder to
> debug error.
> 
> The better approach to fix your problem is: make the driver depend (or
> force) on GPIOLIB. 

It was one of the solutions I had in mind, but:
- since the dependency on GPIOLIB was not included on the patch
- and given that the previous code had provision to work without GPIO
I thought it was an overlook.

>Or alternatively, drop reset-handling from the
> driver.
> 
> From a driver perspecitive, it would be nice if devm_gpiod_get_optional
> returned NULL iff the respective gpio isn't specified even with
> GPIOLIB=n, but this isn't sensible either because it would result in
> quite some gpiolib code to not being conditionally compiled on
> CONFIG_GPIOLIB any more.

Let's say that was the case, what would the PHY code do?

I mean, it did not get a GPIO, whether it was because GPIOLIB=n or
because there's no 'reset' GPIO attached
Shall it fail? Shall it continue in a sort of degraded mode? Shall it warn?
Because that's the real question here.

What would you think of making at803x_link_change_notify() print a
message every time it should do a reset but does not has a way to do it?
I can make such change to my patch if everybody agrees on it.
By the way, in that case, can somebody suggest a way to print such warning?
Would printk() be ok or should I use dev_dbg() ?

Best regards,

Sebastian

> 
> Best regards
> Uwe
> 

^ permalink raw reply

* Re: [net-next v2] virtio_net: replace netdev_alloc_skb_ip_align() with napi_alloc_skb()
From: Venkatesh Srinivas @ 2016-03-18 15:58 UTC (permalink / raw)
  To: Paolo Abeni
  Cc: netdev, Michael S. Tsirkin, virtualization, Hannes Frederic Sowa
In-Reply-To: <98c94ca899603eb4212c44aa1a658825198ed49a.1458290241.git.pabeni@redhat.com>

On Fri, Mar 18, 2016 at 8:42 AM, Paolo Abeni <pabeni@redhat.com> wrote:
> This gives small but noticeable rx performance improvement (2-3%)
> and will allow exploiting future napi improvement.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>
> --
>  v2: replace also netdev_alloc_skb_ip_align() invocation in
>         add_recvbuf_small(), suggested by Venkatesh Srinivas
> ---
>  drivers/net/virtio_net.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index fb0eae4..100e039 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -260,7 +260,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
>         p = page_address(page) + offset;
>
>         /* copy small packet so we can reuse these pages for small data */
> -       skb = netdev_alloc_skb_ip_align(vi->dev, GOOD_COPY_LEN);
> +       skb = napi_alloc_skb(&rq->napi, GOOD_COPY_LEN);
>         if (unlikely(!skb))
>                 return NULL;
>
> @@ -541,7 +541,7 @@ static int add_recvbuf_small(struct virtnet_info *vi, struct receive_queue *rq,
>         struct virtio_net_hdr_mrg_rxbuf *hdr;
>         int err;
>
> -       skb = __netdev_alloc_skb_ip_align(vi->dev, GOOD_PACKET_LEN, gfp);
> +       skb = __napi_alloc_skb(&rq->napi, GOOD_PACKET_LEN, gfp);
>         if (unlikely(!skb))
>                 return -ENOMEM;

Sorry, I should've mentioned more in my first reply --
add_recvbuf_small is called from try_fill_recv in both
NAPI and non-NAPI context (NAPI: via virtnet_receive from
virtnet_poll; non-NAPI: via scheduled work,
via virtnet_probe, and via virtnet_restore).

I don't believe you can use __napi_alloc_skb() for the non-NAPI paths,
it'd be a bit more work to plumb
the context as an argument if you think its worth doing here.

Looking forward to bulk skb allocation either way.

HTH,
-- vs;

^ permalink raw reply

* Re: [PATCH v5 2/4] Documentation: Bindings: Add STM32 DWMAC glue
From: Chen-Yu Tsai @ 2016-03-18 16:00 UTC (permalink / raw)
  To: Alexandre TORGUE
  Cc: Maxime Coquelin, Giuseppe Cavallaro, netdev, devicetree,
	Joachim Eastwood, linux-kernel, linux-arm-kernel
In-Reply-To: <1458315428-10081-3-git-send-email-alexandre.torgue-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Hi,

On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE
<alexandre.torgue-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Signed-off-by: Alexandre TORGUE <alexandre.torgue-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
> new file mode 100644
> index 0000000..ada2aa4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
> @@ -0,0 +1,32 @@
> +STMicroelectronics STM32 / MCU DWMAC glue layer controller
> +
> +This file documents platform glue layer for stmmac.
> +Please see stmmac.txt for the other unchanged properties.
> +
> +The device node has following properties.
> +
> +Required properties:
> +- compatible:  Should be "st,stm32-dwmac" to select glue, and
> +              "snps,dwmac-3.50a" to select IP vesrion.

If you need have sort of hardware glue, then it is not compatible.

ChenYu

> +- clocks: Must contain a phandle for each entry in clock-names.
> +- clock-names: Should be "stmmaceth" for the host clock.
> +              Should be "tx-clk" for the MAC TX clock.
> +              Should be "rx-clk" for the MAC RX clock.
> +- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
> +             encompases the glue register, and the offset of the control register.
> +Example:
> +
> +               ethernet0: dwmac@40028000 {
> +                       compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
> +                       status = "disabled";
> +                       reg = <0x40028000 0x8000>;
> +                       reg-names = "stmmaceth";
> +                       interrupts = <0 61 0>, <0 62 0>;
> +                       interrupt-names = "macirq", "eth_wake_irq";
> +                       clock-names = "stmmaceth", "tx-clk", "rx-clk";
> +                       clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
> +                       st,syscon = <&syscfg 0x4>;
> +                       snps,pbl = <8>;
> +                       snps,mixed-burst;
> +                       dma-ranges;
> +               };
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH] mac80211: add doc for RX_FLAG_DUP_VALIDATED flag
From: Luis de Bethencourt @ 2016-03-18 16:09 UTC (permalink / raw)
  To: linux-kernel; +Cc: johannes, davem, linux-wireless, netdev, Luis de Bethencourt

Add documentation for the flag for duplication check.

Fixes the following warning when running make htmldocs:
warning: Enum value 'RX_FLAG_DUP_VALIDATED' not described in enum 'mac80211_rx_flags'

Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
---
Hi,

While running make htmldocs I noticed a warning about RX_FLAG_DUP_VALIDATED
missing a description. This patch fixes this.

I have noticed the order of the descriptions of the mac80211_rx_flags doesn't
match the order in the enum. I am happy to fix this if it would be of interest.

Thanks,
Luis

 include/net/mac80211.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index a53333c..42c8cde 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1001,6 +1001,8 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
  *	flag indicates that the PN was verified for replay protection.
  *	Note that this flag is also currently only supported when a frame
  *	is also decrypted (ie. @RX_FLAG_DECRYPTED must be set)
+ * @RX_FLAG_DUP_VALIDATED: Set this flag for the driver to check for packet
+ *	duplication by itself.
  * @RX_FLAG_FAILED_FCS_CRC: Set this flag if the FCS check failed on
  *	the frame.
  * @RX_FLAG_FAILED_PLCP_CRC: Set this flag if the PCLP check failed on
-- 
2.5.1

^ permalink raw reply related

* [PATCH] wl12xx: remove redundant null check on wl->scan.ssid
From: Colin King @ 2016-03-18 16:20 UTC (permalink / raw)
  To: Kalle Valo, Arik Nemtsov, Luca Coelho, Avraham Stern,
	Eliad Peller, linux-wireless, netdev
  Cc: linux-kernel

From: Colin Ian King <colin.king@canonical.com>

ssid is an array of u8, so it can never be null, so the null check on
wl->scan.ssid is redundant and can be removed.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 drivers/net/wireless/ti/wl12xx/scan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ti/wl12xx/scan.c b/drivers/net/wireless/ti/wl12xx/scan.c
index ebed13a..a0dfc59 100644
--- a/drivers/net/wireless/ti/wl12xx/scan.c
+++ b/drivers/net/wireless/ti/wl12xx/scan.c
@@ -149,7 +149,7 @@ static int wl1271_scan_send(struct wl1271 *wl, struct wl12xx_vif *wlvif,
 	else
 		cmd->params.band = WL1271_SCAN_BAND_5_GHZ;
 
-	if (wl->scan.ssid_len && wl->scan.ssid) {
+	if (wl->scan.ssid_len) {
 		cmd->params.ssid_len = wl->scan.ssid_len;
 		memcpy(cmd->params.ssid, wl->scan.ssid, wl->scan.ssid_len);
 	}
-- 
2.7.3

^ permalink raw reply related

* [PATCH] mac80211: fix order of flag descriptions
From: Luis de Bethencourt @ 2016-03-18 16:35 UTC (permalink / raw)
  To: linux-kernel; +Cc: johannes, davem, linux-wireless, netdev, Luis de Bethencourt
In-Reply-To: <1458317369-28185-1-git-send-email-luisbg@osg.samsung.com>

Fix order of mac80211_rx_flags description to match the enum.

Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
---
Hi,

I want ahead and fixed the order of the descriptions. checkpatch.pl was giving
a warning to my previous patch and I had a hunch it was because the wrong order
breaks the parser. Indeed it does and with this patch below checkpatch.pl does
not complain about this flag descriptions anymore.

Thanks,
Luis

 include/net/mac80211.h | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 42c8cde..4b215a3 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -992,17 +992,13 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
  * @RX_FLAG_MMIC_ERROR: Michael MIC error was reported on this frame.
  *	Use together with %RX_FLAG_MMIC_STRIPPED.
  * @RX_FLAG_DECRYPTED: This frame was decrypted in hardware.
+ * @RX_FLAG_MACTIME_PLCP_START: The timestamp passed in the RX status (@mactime
+ *	field) is valid and contains the time the SYNC preamble was received.
  * @RX_FLAG_MMIC_STRIPPED: the Michael MIC is stripped off this frame,
  *	verification has been done by the hardware.
  * @RX_FLAG_IV_STRIPPED: The IV/ICV are stripped from this frame.
  *	If this flag is set, the stack cannot do any replay detection
  *	hence the driver or hardware will have to do that.
- * @RX_FLAG_PN_VALIDATED: Currently only valid for CCMP/GCMP frames, this
- *	flag indicates that the PN was verified for replay protection.
- *	Note that this flag is also currently only supported when a frame
- *	is also decrypted (ie. @RX_FLAG_DECRYPTED must be set)
- * @RX_FLAG_DUP_VALIDATED: Set this flag for the driver to check for packet
- *	duplication by itself.
  * @RX_FLAG_FAILED_FCS_CRC: Set this flag if the FCS check failed on
  *	the frame.
  * @RX_FLAG_FAILED_PLCP_CRC: Set this flag if the PCLP check failed on
@@ -1011,14 +1007,8 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
  *	field) is valid and contains the time the first symbol of the MPDU
  *	was received. This is useful in monitor mode and for proper IBSS
  *	merging.
- * @RX_FLAG_MACTIME_END: The timestamp passed in the RX status (@mactime
- *	field) is valid and contains the time the last symbol of the MPDU
- *	(including FCS) was received.
- * @RX_FLAG_MACTIME_PLCP_START: The timestamp passed in the RX status (@mactime
- *	field) is valid and contains the time the SYNC preamble was received.
  * @RX_FLAG_SHORTPRE: Short preamble was used for this frame
  * @RX_FLAG_HT: HT MCS was used and rate_idx is MCS index
- * @RX_FLAG_VHT: VHT MCS was used and rate_index is MCS index
  * @RX_FLAG_40MHZ: HT40 (40 MHz) was used
  * @RX_FLAG_SHORT_GI: Short guard interval was used
  * @RX_FLAG_NO_SIGNAL_VAL: The signal strength value is not present.
@@ -1029,6 +1019,12 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
  * @RX_FLAG_AMPDU_DETAILS: A-MPDU details are known, in particular the reference
  *	number (@ampdu_reference) must be populated and be a distinct number for
  *	each A-MPDU
+ * @RX_FLAG_PN_VALIDATED: Currently only valid for CCMP/GCMP frames, this
+ *	flag indicates that the PN was verified for replay protection.
+ *	Note that this flag is also currently only supported when a frame
+ *	is also decrypted (ie. @RX_FLAG_DECRYPTED must be set)
+ * @RX_FLAG_DUP_VALIDATED: Set this flag for the driver to check for packet
+ *	duplication by itself.
  * @RX_FLAG_AMPDU_LAST_KNOWN: last subframe is known, should be set on all
  *	subframes of a single A-MPDU
  * @RX_FLAG_AMPDU_IS_LAST: this subframe is the last subframe of the A-MPDU
@@ -1036,8 +1032,10 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
  *	on this subframe
  * @RX_FLAG_AMPDU_DELIM_CRC_KNOWN: The delimiter CRC field is known (the CRC
  *	is stored in the @ampdu_delimiter_crc field)
- * @RX_FLAG_MIC_STRIPPED: The mic was stripped of this packet. Decryption was
- *	done by the hardware
+ * @RX_FLAG_MACTIME_END: The timestamp passed in the RX status (@mactime
+ *	field) is valid and contains the time the last symbol of the MPDU
+ *	(including FCS) was received.
+ * @RX_FLAG_VHT: VHT MCS was used and rate_index is MCS index
  * @RX_FLAG_LDPC: LDPC was used
  * @RX_FLAG_ONLY_MONITOR: Report frame only to monitor interfaces without
  *	processing it in any regular way.
@@ -1062,6 +1060,8 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
  * @RX_FLAG_RADIOTAP_VENDOR_DATA: This frame contains vendor-specific
  *	radiotap data in the skb->data (before the frame) as described by
  *	the &struct ieee80211_vendor_radiotap.
+ * @RX_FLAG_MIC_STRIPPED: The mic was stripped of this packet. Decryption was
+ *	done by the hardware
  */
 enum mac80211_rx_flags {
 	RX_FLAG_MMIC_ERROR		= BIT(0),
-- 
2.5.1

^ permalink raw reply related

* Re: [PATCH] mac80211: fix order of flag descriptions
From: Johannes Berg @ 2016-03-18 16:49 UTC (permalink / raw)
  To: Luis de Bethencourt, linux-kernel; +Cc: davem, linux-wireless, netdev
In-Reply-To: <1458318955-32070-1-git-send-email-luisbg@osg.samsung.com>

On Fri, 2016-03-18 at 16:35 +0000, Luis de Bethencourt wrote:
> Fix order of mac80211_rx_flags description to match the enum.
> 
> Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
> ---
> Hi,
> 
> I want ahead and fixed the order of the descriptions. checkpatch.pl
> was giving
> a warning to my previous patch and I had a hunch it was because the
> wrong order
> breaks the parser. Indeed it does and with this patch below
> checkpatch.pl does
> not complain about this flag descriptions anymore.
> 
Huh. I think we should fix checkpatch.pl instead. While the current
order isn't likely really good, I believe kernel-doc will output the
documentation in the order it's listed, and that can be useful for the
documentation output to group related things, even if their bits may be
further apart.

johannes

^ permalink raw reply

* [linux-next:master 8604/12950] net/openvswitch/vport-internal_dev.c:141:6: sparse: symbol 'internal_set_rx_headroom' was not declared. Should it be static?
From: kbuild test robot @ 2016-03-18 16:54 UTC (permalink / raw)
  To: Paolo Abeni
  Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
	kbuild-all-JC7UmRfGjtg, linux-kernel-u79uwXL29TY76Z2rM5mHXA

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head:   5e3497cca281616e7930b74a0076b7324dcc2057
commit: 3a927bc7cf9d0fbe8f4a8189dd5f8440228f64e7 [8604/12950] ovs: propagate per dp max headroom to all vports
reproduce:
        # apt-get install sparse
        git checkout 3a927bc7cf9d0fbe8f4a8189dd5f8440228f64e7
        make ARCH=x86_64 allmodconfig
        make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> net/openvswitch/vport-internal_dev.c:141:6: sparse: symbol 'internal_set_rx_headroom' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply

* [RFC PATCH linux-next] ovs: internal_set_rx_headroom() can be static
From: kbuild test robot @ 2016-03-18 16:54 UTC (permalink / raw)
  To: Paolo Abeni
  Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
	kbuild-all-JC7UmRfGjtg, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201603190023.RJCVrbEg%fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>


Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
 vport-internal_dev.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/openvswitch/vport-internal_dev.c b/net/openvswitch/vport-internal_dev.c
index 83a5534..7c8b90b 100644
--- a/net/openvswitch/vport-internal_dev.c
+++ b/net/openvswitch/vport-internal_dev.c
@@ -138,7 +138,7 @@ internal_get_stats(struct net_device *dev, struct rtnl_link_stats64 *stats)
 	return stats;
 }
 
-void internal_set_rx_headroom(struct net_device *dev, int new_hr)
+static void internal_set_rx_headroom(struct net_device *dev, int new_hr)
 {
 	dev->needed_headroom = new_hr;
 }
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply related

* Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket
From: Cong Wang @ 2016-03-18 17:19 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: David Miller, weiwan, Eric Dumazet,
	Linux Kernel Network Developers
In-Reply-To: <1458185652.7353.28.camel@edumazet-glaptop3.roam.corp.google.com>

On Wed, Mar 16, 2016 at 8:34 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2016-03-16 at 22:38 -0400, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Wed, 16 Mar 2016 17:22:07 -0700
>>
>> > One of the issue is that IPV6_MTU getsockopt() will not check the dst,
>> > but simply use __sk_dst_get() : It will then report old mtu.
>>
>> That's a bug.
>>
>> ipv4 does it right with a proper sk_dst_get() and so should
>> ipv6.
>
> Using rcu + __sk_dst_get() (in IPv6) is absolutely equivalent to
> sk_dst_get() + dst_release() (in IPv4), modulo atomic ops on dst
> refcnt...
>
> Presumably IPv6 implementation using rcu is slightly better if this
> getsockopt() is badly needed, but apparently nobody cares.
>
> sk_dst_check() is a different beast.
>
> The problem is that dst_mtu(dst) is not able to perform a route lookup
> by itself.
>
> Do we really want to use ip6_sk_dst_lookup_flow() and its associated
> setup for this IP6_MTU thing, and maybe other points we might use an
> obsolete dst ?
>
> Looking at the complexity of udpv6_sendmsg() and rawv6_sendmsg() I
> really wonder if it is worth extracting the route logic.

I think the reason why IPv4 does this correctly is ipv4_sk_update_pmtu()
takes care of the sk cached dst, while the similar part for IPv6,
ip6_sk_update_pmtu() does not that. As Martin already points it out
in the previous version.

^ permalink raw reply

* Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables
From: Murali Karicheri @ 2016-03-18 17:25 UTC (permalink / raw)
  To: Ido Schimmel, Andrew Lunn; +Cc: David Miller, sfeldma, netdev, jiri
In-Reply-To: <20160317215314.GA4925@colbert.idosch.org>

On 03/17/2016 05:53 PM, Ido Schimmel wrote:
> Thu, Mar 17, 2016 at 10:25:19PM IST, andrew@lunn.ch wrote:
>> On Thu, Mar 17, 2016 at 04:10:31PM -0400, Murali Karicheri wrote:
>>> David,
>>>
>>> On 08/18/2015 04:47 PM, David Miller wrote:
>>>> I see some drivers where the foo_debugfs.c file is larger than the rest
>>>> of the driver.  Once people start using it, it's like crack, and they
>>>> dump every single debugging widget they found useful at some point into
>>>> there.
>>>>
>>>> This is not what we want.  Most things I see in debugfs support was
>>>> probably useful for debugging one particular bug but then it was never
>>>> really useful again in the future.  Those kinds of things can be done
>>>> locally in someone's tree.
>>>>
>>>> I often see various kinds of "statistics" ending up in these things,
>>>> or register dumps, both of which are 'ethtool' or similar material.
>>> Very late to this discussion, but I need to port some of the internal code
>>> to display the content of a ALE (Address Learning Engine) table maintained
>>> in hardwareat L2 layer. Currently I have a sysfs implementation that dumps
>>> information like below.
>>>
>>> root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
>>> index 0, raw: 000007fc d000ffff ffffffff, type: addr(1), addr: ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
>>> index 1, raw: 00000000 10000800 28329a1c, type: addr(1), addr: 08:00:28:32:9a:1c, uctype: persistent(0), port: 0
>>> index 2, raw: 000007fc d0000100 5e000001, type: addr(1), addr: 01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
>>> index 19, raw: 00000004 d000d4be d93db6c1, type: addr(1), addr: d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
>>>
>>> What is the available interface in kernel to expose this information
>>> to user space as debugfs is not suggested based on this thread?
>>
>> This looks a lot like what the mv88e6xxx_port_fdb_dump() callback
>> returns to DSA when SWITCHDEV_OBJ_ID_PORT_FDB is passed to
>> switchdev_port_obj_dump() in the switchdev ops.
> 
> +1
> 
> Also, Murali, using standard interfaces instead of debugfs will allow
> you to:
> 
> 1) Upstream your code
> 2) Use existing tests for your code. In particular, the following
> (which is used for mlxsw testing):
> 
> https://github.com/jpirko/lnst/blob/master/recipes/switchdev/l2-002-bridge_fdb.py
> 
> There are a bunch of others there which you'll probably find useful.
> 
> BTW, are you familiar with the following document?
> https://www.kernel.org/doc/Documentation/networking/switchdev.txt
> I believe it answers your question.

Yes. I have support for DSA and switchdev for netcp driver in my TODO list.
Will post more questions on this once I start work on this.

Thanks

Murali
> 
> Good luck!
> 
>>
>> 	  Andrew
> 


-- 
Murali Karicheri
Linux Kernel, Keystone

^ permalink raw reply

* Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables
From: Murali Karicheri @ 2016-03-18 17:29 UTC (permalink / raw)
  To: Florian Fainelli, Andrew Lunn; +Cc: David Miller, sfeldma, netdev, jiri
In-Reply-To: <56EB3B2D.40509@gmail.com>

On 03/17/2016 07:18 PM, Florian Fainelli wrote:
> On 17/03/16 13:48, Murali Karicheri wrote:
>> On 03/17/2016 04:25 PM, Andrew Lunn wrote:
>>> On Thu, Mar 17, 2016 at 04:10:31PM -0400, Murali Karicheri wrote:
>>>> David,
>>>>
>>>> On 08/18/2015 04:47 PM, David Miller wrote:
>>>>> I see some drivers where the foo_debugfs.c file is larger than the rest
>>>>> of the driver.  Once people start using it, it's like crack, and they
>>>>> dump every single debugging widget they found useful at some point into
>>>>> there.
>>>>>
>>>>> This is not what we want.  Most things I see in debugfs support was
>>>>> probably useful for debugging one particular bug but then it was never
>>>>> really useful again in the future.  Those kinds of things can be done
>>>>> locally in someone's tree.
>>>>>
>>>>> I often see various kinds of "statistics" ending up in these things,
>>>>> or register dumps, both of which are 'ethtool' or similar material.
>>>> Very late to this discussion, but I need to port some of the internal code
>>>> to display the content of a ALE (Address Learning Engine) table maintained
>>>> in hardwareat L2 layer. Currently I have a sysfs implementation that dumps
>>>> information like below.
>>>>
>>>> root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
>>>> index 0, raw: 000007fc d000ffff ffffffff, type: addr(1), addr: ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
>>>> index 1, raw: 00000000 10000800 28329a1c, type: addr(1), addr: 08:00:28:32:9a:1c, uctype: persistent(0), port: 0
>>>> index 2, raw: 000007fc d0000100 5e000001, type: addr(1), addr: 01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
>>>> index 19, raw: 00000004 d000d4be d93db6c1, type: addr(1), addr: d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
>>>>
>>>> What is the available interface in kernel to expose this information
>>>> to user space as debugfs is not suggested based on this thread?
>>>
>>> This looks a lot like what the mv88e6xxx_port_fdb_dump() callback
>>> returns to DSA when SWITCHDEV_OBJ_ID_PORT_FDB is passed to
>>> switchdev_port_obj_dump() in the switchdev ops.
>>>
>> Andrew,
>>
>> Which tool user has to use to get this dump once implemented?
> 
> iproute2's bridge command with bridge fdb show <interface>.
> 
Thanks

-- 
Murali Karicheri
Linux Kernel, Keystone

^ permalink raw reply

* Re: [PATCH] mac80211: fix order of flag descriptions
From: Joe Perches @ 2016-03-18 17:29 UTC (permalink / raw)
  To: Luis de Bethencourt, linux-kernel; +Cc: johannes, davem, linux-wireless, netdev
In-Reply-To: <1458318955-32070-1-git-send-email-luisbg@osg.samsung.com>

On Fri, 2016-03-18 at 16:35 +0000, Luis de Bethencourt wrote:
> Fix order of mac80211_rx_flags description to match the enum.
> 
> Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
> ---
> Hi,
> 
> I want ahead and fixed the order of the descriptions. checkpatch.pl was giving
> a warning to my previous patch and I had a hunch it was because the wrong order
> breaks the parser. Indeed it does and with this patch below checkpatch.pl does
> not complain about this flag descriptions anymore.

checkpatch complains?  About what?

^ permalink raw reply

* [PATCH net 3/3] ipv6, trace: fix tos reporting on fib6_table_lookup
From: Daniel Borkmann @ 2016-03-18 17:37 UTC (permalink / raw)
  To: davem
  Cc: jbenc, linville, jesse, dsa, alexei.starovoitov, netdev,
	Daniel Borkmann
In-Reply-To: <cover.1458320940.git.daniel@iogearbox.net>

flowi6_tos of struct flowi6 is unused in IPv6, therefore dumping tos on
that tracepoint will also give incorrect information wrt traffic class.

If we want to fix it, we need to extract it via ip6_tclass(flp->flowlabel).
While for the same test case I get a count of 0 non-zero tos values before
the change, they now start to show up after the change:

  # ./perf record -e fib6:fib6_table_lookup -a sleep 10
  # ./perf script | grep -v "tos 0" | wc -l
  60

Since there's no user in the kernel tree anymore of flowi6_tos, remove the
define to avoid any future confusion on this.

Fixes: b811580d91e9 ("net: IPv6 fib lookup tracepoint")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
 include/net/flow.h          | 2 +-
 include/trace/events/fib6.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/net/flow.h b/include/net/flow.h
index 83969ee..d47ef4b 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -127,7 +127,6 @@ struct flowi6 {
 #define flowi6_oif		__fl_common.flowic_oif
 #define flowi6_iif		__fl_common.flowic_iif
 #define flowi6_mark		__fl_common.flowic_mark
-#define flowi6_tos		__fl_common.flowic_tos
 #define flowi6_scope		__fl_common.flowic_scope
 #define flowi6_proto		__fl_common.flowic_proto
 #define flowi6_flags		__fl_common.flowic_flags
@@ -135,6 +134,7 @@ struct flowi6 {
 #define flowi6_tun_key		__fl_common.flowic_tun_key
 	struct in6_addr		daddr;
 	struct in6_addr		saddr;
+	/* Note: flowi6_tos is encoded in flowlabel, too. */
 	__be32			flowlabel;
 	union flowi_uli		uli;
 #define fl6_sport		uli.ports.sport
diff --git a/include/trace/events/fib6.h b/include/trace/events/fib6.h
index 4cf6bac..d60096c 100644
--- a/include/trace/events/fib6.h
+++ b/include/trace/events/fib6.h
@@ -37,7 +37,7 @@ TRACE_EVENT(fib6_table_lookup,
 		__entry->tb_id = tb_id;
 		__entry->oif = flp->flowi6_oif;
 		__entry->iif = flp->flowi6_iif;
-		__entry->tos = flp->flowi6_tos;
+		__entry->tos = ip6_tclass(flp->flowlabel);
 		__entry->scope = flp->flowi6_scope;
 		__entry->flags = flp->flowi6_flags;
 
-- 
1.9.3

^ permalink raw reply related

* [PATCH net 1/3] vxlan: fix populating tclass in vxlan6_get_route
From: Daniel Borkmann @ 2016-03-18 17:37 UTC (permalink / raw)
  To: davem
  Cc: jbenc, linville, jesse, dsa, alexei.starovoitov, netdev,
	Daniel Borkmann
In-Reply-To: <cover.1458320940.git.daniel@iogearbox.net>

Jiri mentioned that flowi6_tos of struct flowi6 is never used/read
anywhere. In fact, rest of the kernel uses the flowi6's flowlabel,
where the traffic class _and_ the flowlabel (aka flowinfo) is encoded.

For example, for policy routing, fib6_rule_match() uses ip6_tclass()
that is applied on the flowlabel member for matching on tclass. Similar
fix is needed for geneve, where flowi6_tos is set as well. Installing
a v6 blackhole rule that f.e. matches on tos is now working with vxlan.

Fixes: 1400615d64cf ("vxlan: allow setting ipv6 traffic class")
Reported-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
 drivers/net/vxlan.c | 3 +--
 include/net/ipv6.h  | 6 ++++++
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 800106a7..7bfcb9a62a 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1810,10 +1810,9 @@ static struct dst_entry *vxlan6_get_route(struct vxlan_dev *vxlan,
 
 	memset(&fl6, 0, sizeof(fl6));
 	fl6.flowi6_oif = oif;
-	fl6.flowi6_tos = RT_TOS(tos);
 	fl6.daddr = *daddr;
 	fl6.saddr = vxlan->cfg.saddr.sin6.sin6_addr;
-	fl6.flowlabel = label;
+	fl6.flowlabel = ip6_make_flowinfo(RT_TOS(tos), label);
 	fl6.flowi6_mark = skb->mark;
 	fl6.flowi6_proto = IPPROTO_UDP;
 
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index f3c9857..d0aeb97 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -835,6 +835,12 @@ static inline u8 ip6_tclass(__be32 flowinfo)
 {
 	return ntohl(flowinfo & IPV6_TCLASS_MASK) >> IPV6_TCLASS_SHIFT;
 }
+
+static inline __be32 ip6_make_flowinfo(unsigned int tclass, __be32 flowlabel)
+{
+	return htonl(tclass << IPV6_TCLASS_SHIFT) | flowlabel;
+}
+
 /*
  *	Prototypes exported by ipv6
  */
-- 
1.9.3

^ permalink raw reply related

* [PATCH net 0/3] flowi6_tos fixes
From: Daniel Borkmann @ 2016-03-18 17:37 UTC (permalink / raw)
  To: davem
  Cc: jbenc, linville, jesse, dsa, alexei.starovoitov, netdev,
	Daniel Borkmann

This set is a follow-up to address Jiri's recent feedback [1] on
the flowi6_tos issue, that it is not used for IPv6 route lookups.
The three patches fix all current users of flowi6_tos and remove
the define to avoid any future confusion on this. Tested the vxlan
and geneve ones with IPv6 routing rules. For details, please see
individual patches.

[ As fixes are currently applied against net-next tree, I've rebased
  it against that. ]

Thanks!

  [1] http://patchwork.ozlabs.org/patch/592055/

Daniel Borkmann (3):
  vxlan: fix populating tclass in vxlan6_get_route
  geneve: fix populating tclass in geneve_get_v6_dst
  ipv6, trace: fix tos reporting on fib6_table_lookup

 drivers/net/geneve.c        | 11 ++++++-----
 drivers/net/vxlan.c         |  3 +--
 include/net/flow.h          |  2 +-
 include/net/ipv6.h          |  6 ++++++
 include/trace/events/fib6.h |  2 +-
 5 files changed, 15 insertions(+), 9 deletions(-)

-- 
1.9.3

^ permalink raw reply

* [PATCH net 2/3] geneve: fix populating tclass in geneve_get_v6_dst
From: Daniel Borkmann @ 2016-03-18 17:37 UTC (permalink / raw)
  To: davem
  Cc: jbenc, linville, jesse, dsa, alexei.starovoitov, netdev,
	Daniel Borkmann
In-Reply-To: <cover.1458320940.git.daniel@iogearbox.net>

The struct flowi6's flowi6_tos is not used in IPv6 route lookup, the
traffic class information is handled in the flowi6's flowlabel member
instead. For example, for policy routing, fib6_rule_match() uses
ip6_tclass() that is applied on the flowlabel for matching on tclass,
which would currently not work as expected.

Fixes: 3a56f86f1be6 ("geneve: handle ipv6 priority like ipv4 tos")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
 drivers/net/geneve.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 192631a..bc16889 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -843,8 +843,8 @@ static struct dst_entry *geneve_get_v6_dst(struct sk_buff *skb,
 	if (info) {
 		fl6->daddr = info->key.u.ipv6.dst;
 		fl6->saddr = info->key.u.ipv6.src;
-		fl6->flowi6_tos = RT_TOS(info->key.tos);
-		fl6->flowlabel = info->key.label;
+		fl6->flowlabel = ip6_make_flowinfo(RT_TOS(info->key.tos),
+						   info->key.label);
 		dst_cache = &info->dst_cache;
 	} else {
 		prio = geneve->tos;
@@ -855,8 +855,8 @@ static struct dst_entry *geneve_get_v6_dst(struct sk_buff *skb,
 			use_cache = false;
 		}
 
-		fl6->flowi6_tos = RT_TOS(prio);
-		fl6->flowlabel = geneve->label;
+		fl6->flowlabel = ip6_make_flowinfo(RT_TOS(prio),
+						   geneve->label);
 		fl6->daddr = geneve->remote.sin6.sin6_addr;
 		dst_cache = &geneve->dst_cache;
 	}
@@ -1049,7 +1049,8 @@ static netdev_tx_t geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev,
 		if (unlikely(err))
 			goto err;
 
-		prio = ip_tunnel_ecn_encap(fl6.flowi6_tos, iip, skb);
+		prio = ip_tunnel_ecn_encap(ip6_tclass(fl6.flowlabel),
+					   iip, skb);
 		ttl = geneve->ttl;
 		if (!ttl && ipv6_addr_is_multicast(&fl6.daddr))
 			ttl = 1;
-- 
1.9.3

^ permalink raw reply related

* Re: [PATCH] mac80211: fix order of flag descriptions
From: Luis de Bethencourt @ 2016-03-18 17:40 UTC (permalink / raw)
  To: Joe Perches, linux-kernel; +Cc: johannes, davem, linux-wireless, netdev
In-Reply-To: <1458322179.26915.2.camel@perches.com>

On 18/03/16 17:29, Joe Perches wrote:
> On Fri, 2016-03-18 at 16:35 +0000, Luis de Bethencourt wrote:
>> Fix order of mac80211_rx_flags description to match the enum.
>>
>> Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
>> ---
>> Hi,
>>
>> I want ahead and fixed the order of the descriptions. checkpatch.pl was giving
>> a warning to my previous patch and I had a hunch it was because the wrong order
>> breaks the parser. Indeed it does and with this patch below checkpatch.pl does
>> not complain about this flag descriptions anymore.
> 
> checkpatch complains?  About what?
> 

warning: Enum value 'RX_FLAG_DUP_VALIDATED' not described in enum 'mac80211_rx_flags'

Is the warning checkpatch.pl gives against my first patch (add doc for
RX_FLAG_DUP_VALIDATED flag). This is silenced by reordering the descriptions to match
the order in the enum.

Thanks,
Luis

^ permalink raw reply

* Re: [PATCH] mac80211: fix order of flag descriptions
From: Joe Perches @ 2016-03-18 17:46 UTC (permalink / raw)
  To: Luis de Bethencourt, linux-kernel; +Cc: johannes, davem, linux-wireless, netdev
In-Reply-To: <56EC3DA6.2090105@osg.samsung.com>

On Fri, 2016-03-18 at 17:40 +0000, Luis de Bethencourt wrote:
> On 18/03/16 17:29, Joe Perches wrote:
> > On Fri, 2016-03-18 at 16:35 +0000, Luis de Bethencourt wrote:
> > > Fix order of mac80211_rx_flags description to match the enum.
[]
> > > I want ahead and fixed the order of the descriptions. checkpatch.pl was giving
> > > a warning to my previous patch and I had a hunch it was because the wrong order
> > > breaks the parser. Indeed it does and with this patch below checkpatch.pl does
> > > not complain about this flag descriptions anymore.
> > checkpatch complains?  About what?
> warning: Enum value 'RX_FLAG_DUP_VALIDATED' not described in enum 'mac80211_rx_flags'

That's not a checkpatch warning.

cheers, Joe

^ permalink raw reply

* Re: [PATCH] mac80211: fix order of flag descriptions
From: Luis de Bethencourt @ 2016-03-18 17:46 UTC (permalink / raw)
  To: Johannes Berg, linux-kernel; +Cc: davem, linux-wireless, netdev
In-Reply-To: <1458319756.13729.1.camel@sipsolutions.net>

On 18/03/16 16:49, Johannes Berg wrote:
> On Fri, 2016-03-18 at 16:35 +0000, Luis de Bethencourt wrote:
>> Fix order of mac80211_rx_flags description to match the enum.
>>
>> Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
>> ---
>> Hi,
>>
>> I want ahead and fixed the order of the descriptions. checkpatch.pl
>> was giving
>> a warning to my previous patch and I had a hunch it was because the
>> wrong order
>> breaks the parser. Indeed it does and with this patch below
>> checkpatch.pl does
>> not complain about this flag descriptions anymore.
>>
> Huh. I think we should fix checkpatch.pl instead. While the current
> order isn't likely really good, I believe kernel-doc will output the
> documentation in the order it's listed, and that can be useful for the
> documentation output to group related things, even if their bits may be
> further apart.
> 
> johannes
> 

I agree checkpatch.pl should be fixed. I can look into it. No promises
though, it has been a long time since I look at Perl code.

I understand the logic of grouping the documentation in logical blocks.
It is unfortunate though that this means the enum and documentation won't
match, which makes reading the code harder.

In this particular case I don't see the order of the documentation broken
because flags are being grouped.

Thanks for the review :)
Luis

^ permalink raw reply

* Re: [PATCH] mac80211: fix order of flag descriptions
From: Luis de Bethencourt @ 2016-03-18 17:49 UTC (permalink / raw)
  To: Joe Perches, linux-kernel; +Cc: johannes, davem, linux-wireless, netdev
In-Reply-To: <1458323163.26915.8.camel@perches.com>

On 18/03/16 17:46, Joe Perches wrote:
> On Fri, 2016-03-18 at 17:40 +0000, Luis de Bethencourt wrote:
>> On 18/03/16 17:29, Joe Perches wrote:
>>> On Fri, 2016-03-18 at 16:35 +0000, Luis de Bethencourt wrote:
>>>> Fix order of mac80211_rx_flags description to match the enum.
> []
>>>> I want ahead and fixed the order of the descriptions. checkpatch.pl was giving
>>>> a warning to my previous patch and I had a hunch it was because the wrong order
>>>> breaks the parser. Indeed it does and with this patch below checkpatch.pl does
>>>> not complain about this flag descriptions anymore.
>>> checkpatch complains?  About what?
>> warning: Enum value 'RX_FLAG_DUP_VALIDATED' not described in enum 'mac80211_rx_flags'
> 
> That's not a checkpatch warning.
> 
> cheers, Joe
> 

Oh no!

Joe is right. That isn't a checkpatch warning, but checkpatch just printing the line
in my commit message that goes over 75 characters. Which I kept that big to keep the
format from make htmldocs.

I still think the order of the documentation should match the enum regardless, it is
nicer for developers reading the code.

Sorry :( my bad for misinterpreting checkpatch's output.

Thanks you Joe for correcting me,
Luis 

^ permalink raw reply

* Re: [PATCH v6 net-next 2/2] tcp: Add Redundant Data Bundling (RDB)
From: Bendik Rønning Opstad @ 2016-03-18 17:58 UTC (permalink / raw)
  To: Eric Dumazet, Bendik Rønning Opstad
  Cc: David S. Miller, netdev, Yuchung Cheng, Neal Cardwell,
	Andreas Petlund, Carsten Griwodz, Pål Halvorsen,
	Jonas Markussen, Kristian Evensen, Kenneth Klette Jonassen
In-Reply-To: <1457990140.31401.20.camel@edumazet-glaptop3.roam.corp.google.com>

On 14/03/16 22:15, Eric Dumazet wrote:
> Acked-by: Eric Dumazet <edumazet@google.com>
>
> Note that RDB probably should get some SNMP counters,
> so that we get an idea of how many times a loss could be repaired.

Good idea. Simply count how many times an RDB packet successfully
repaired loss? Note that this can be one or more lost packets. When
bundling N packets, the RDB packet can repair up to N losses in the
previous N packets that were sent.

Which list should this be added to? snmp4_tcp_list?

Any other counters that would be useful? Total number of RDB packets
transmitted?

> Ideally, if the path happens to be lossless, all these pro active
> bundles are overhead. Might be useful to make RDB conditional to
> tp->total_retrans or something.

Yes, that is a good point. We have discussed this (for years really),
but have not had the opportunity to investigate it in-depth. Having
such a condition hard coded is not ideal, as it very much depends on
the use case if bundling from the beginning is desirable. In most
cases, this is probably a fair compromise, but preferably we would
have some logic/settings to control how the bundling rate can be
dynamically adjusted in response to certain events, defined by a set
of given metrics.

A conservative (default) setting would not do bundling until loss has
been registered, and could also check against some smoothed loss
indicator such that a certain amount of loss must have occurred within
a specific time frame to allow bundling. This could be useful in cases
where the network congestion varies greatly depending on such as the
time of day/night.

In a scenario where minimal application layer latency is very
important, but only sporadic (single) packet loss is expected to
regularly occur, always bundling one previous packet may be both
sufficient and desirable.

In the end, the best settings for an application/service depends on
the degree to which application layer latency (both minimal and
variations) affects the QoE.

There are many possibilities to consider in this regard, and I expect
we will not have this question fully explored any time soon. Most
importantly, we should ensure that such logic can easily be added
later on without breaking backwards compatibility.

Suggestions and comments on this are very welcome.


Bendik

^ permalink raw reply

* Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket
From: Cong Wang @ 2016-03-18 18:10 UTC (permalink / raw)
  To: Wei Wang
  Cc: Martin KaFai Lau, Eric Dumazet, David Miller, Eric Dumazet,
	Linux Kernel Network Developers
In-Reply-To: <CAEA6p_CfDYYLf-s0pUy7VNFH+46PDZSXNzUExXRAM_xv2w8tcw@mail.gmail.com>

On Fri, Mar 18, 2016 at 10:45 AM, Wei Wang <weiwan@google.com> wrote:
> Thanks all for the comments.
>
> Cong, you are right that for ipv6, the code does not take care of updating
> sk_dst_cache entry like Ipv4. And this patch is updating the entry by
> calling ip6_dst_store() to achieve similar functionality as Ipv4.

My question is why not updating ip6_sk_update_pmtu() to sync with ipv4?

^ permalink raw reply

* Re: [v6, 3/5] dt: move guts devicetree doc out of powerpc directory
From: Scott Wood @ 2016-03-18 18:16 UTC (permalink / raw)
  To: Rob Herring, Yangbo Lu
  Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-clk@vger.kernel.org, linux-i2c@vger.kernel.org,
	iommu@lists.linux-foundation.org, netdev@vger.kernel.org,
	linux-mmc@vger.kernel.org, Russell King, Jochen Friedrich,
	Joerg Roedel, Claudiu Manoil, ulf.hansson@linaro.org,
	Bhupesh Sharma, Zhao Qiang, Kumar Gala
In-Reply-To: <20160317170640.GB21009@rob-hp-laptop>

On 03/17/2016 12:06 PM, Rob Herring wrote:
> On Wed, Mar 09, 2016 at 06:08:49PM +0800, Yangbo Lu wrote:
>> Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
>> since it's used by not only PowerPC but also ARM. And add a specification
>> for 'little-endian' property.
>>
>> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
>> ---
>> Changes for v2:
>> 	- None
>> Changes for v3:
>> 	- None
>> Changes for v4:
>> 	- Added this patch
>> Changes for v5:
>> 	- Modified the description for little-endian property
>> Changes for v6:
>> 	- None
>> ---
>>  Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
>>  1 file changed, 3 insertions(+)
>>  rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
>>
>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/soc/fsl/guts.txt
>> similarity index 91%
>> rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
>> rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
>> index b71b203..07adca9 100644
>> --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
>> +++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
>> @@ -25,6 +25,9 @@ Recommended properties:
>>   - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
>>     registers, for those SOCs that have a PAMU device.
>>  
>> + - little-endian : Indicates that the global utilities block is little
>> +   endian. The default is big endian.
> 
> The default is "the native endianness of the system". So absence on an 
> ARM system would be LE.

No.  For this binding, the default is big-endian, because that's what
existed for this device before an endian property was added.

"endianness of the system" is not a well-defined concept.

> This property is valid for any simple-bus device, 

Since when does simple-bus mean anything more than that the nodes
underneath it can be used without bus-specific knowledge?

> so it isn't really required to document per device. You can, but 
> your description had better match the documented behaviour.

Documented where?

In fact, Documentation/devicetree/bindings/common-properties.txt
explicitly says of the endian properties, "If a binding supports these
properties, then the binding should also specify the default behavior if
none of these properties are present."

-Scott


^ permalink raw reply

* Re: [PATCH] mac80211: fix order of flag descriptions
From: Luis de Bethencourt @ 2016-03-18 18:20 UTC (permalink / raw)
  To: Johannes Berg, linux-kernel-u79uwXL29TY76Z2rM5mHXA
  Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <56EC3EF1.50805-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>

On 18/03/16 17:46, Luis de Bethencourt wrote:
> On 18/03/16 16:49, Johannes Berg wrote:
>> On Fri, 2016-03-18 at 16:35 +0000, Luis de Bethencourt wrote:
>>> Fix order of mac80211_rx_flags description to match the enum.
>>>
>>> Signed-off-by: Luis de Bethencourt <luisbg-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>>> ---
>>> Hi,
>>>
>>> I want ahead and fixed the order of the descriptions. checkpatch.pl
>>> was giving
>>> a warning to my previous patch and I had a hunch it was because the
>>> wrong order
>>> breaks the parser. Indeed it does and with this patch below
>>> checkpatch.pl does
>>> not complain about this flag descriptions anymore.
>>>
>> Huh. I think we should fix checkpatch.pl instead. While the current
>> order isn't likely really good, I believe kernel-doc will output the
>> documentation in the order it's listed, and that can be useful for the
>> documentation output to group related things, even if their bits may be
>> further apart.
>>
>> johannes
>>
> 
> I agree checkpatch.pl should be fixed. I can look into it. No promises
> though, it has been a long time since I look at Perl code.
> 
> I understand the logic of grouping the documentation in logical blocks.
> It is unfortunate though that this means the enum and documentation won't
> match, which makes reading the code harder.
> 
> In this particular case I don't see the order of the documentation broken
> because flags are being grouped.
> 
> Thanks for the review :)
> Luis
> 

Sorry Johannes,

Update. checkpatch doesn't need fixing and it does see the documentation
independently of the order. It was my mistake.

Joe Perches pointed it out in this email branch:
https://lkml.org/lkml/2016/3/18/532


Thanks for looking into this, sorry for my blunder.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ 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