* [PATCH net-next] net: ipv6: send unsolicited NA if enabled for all interfaces
From: David Ahern @ 2017-04-19 19:05 UTC (permalink / raw)
To: netdev; +Cc: hannes, David Ahern
When arp_notify is set to 1 for either a specific interface or for 'all'
interfaces, gratuitous arp requests are sent. Since ndisc_notify is the
ipv6 equivalent to arp_notify, it should follow the same semantics.
Commit 4a6e3c5def13 sends the NA on admin up. The final piece is checking
devconf_all->ndisc_notify in addition to the per device setting. Add it.
Fixes: 5cb04436eef6 ("ipv6: add knob to send unsolicited ND on link-layer address change")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
net/ipv6/ndisc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index b23822e64228..d310dc41209a 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1753,7 +1753,8 @@ static int ndisc_netdev_event(struct notifier_block *this, unsigned long event,
idev = in6_dev_get(dev);
if (!idev)
break;
- if (idev->cnf.ndisc_notify)
+ if (idev->cnf.ndisc_notify ||
+ net->ipv6.devconf_all->ndisc_notify)
ndisc_send_unsol_na(dev);
in6_dev_put(idev);
break;
--
2.1.4
^ permalink raw reply related
* Re: [patch] socket.7: Document SO_INCOMING_CPU
From: Michael Kerrisk (man-pages) @ 2017-04-19 18:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Francois Saint-Jacques,
linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Eric Dumazet
In-Reply-To: <1492621535.22296.8.camel-XN9IlZ5yJG9HTL0Zs8A6p+yfmBU6pStAUsxypvmhUTTZJqsBc5GL+g@public.gmane.org>
Hi Eric,
[reodering for clarity]
>> On 02/19/2017 09:55 PM, Michael Kerrisk (man-pages) wrote:
>>> [CC += Eric, so that he might review]
>>>
>>> Hello Francois,
>>>
>>> On 02/18/2017 05:06 AM, Francois Saint-Jacques wrote:
>>>> This socket option is undocumented. Applies on the latest version
>>>> (man-pages-4.09-511).
>>>>
>>>> diff --git a/man7/socket.7 b/man7/socket.7
>>>> index 3efd7a5d8..1a3ffa253 100644
>>>> --- a/man7/socket.7
>>>> +++ b/man7/socket.7
>>>> @@ -490,6 +490,26 @@ flag on a socket
>>>> operation.
>>>> Expects an integer boolean flag.
>>>> .TP
>>>> +.BR SO_INCOMING_CPU " (getsockopt since Linux 3.19, setsockopt since
>>>> Linux 4.4)"
>>>> +.\" getsocktop 2c8c56e15df3d4c2af3d656e44feb18789f75837
>>>> +.\" setsocktop 70da268b569d32a9fddeea85dc18043de9d89f89
>>>> +Sets or gets the cpu affinity of a socket. Expects an integer flag.
>>>> +.sp
>>>> +.in +4n
>>>> +.nf
>>>> +int cpu = 1;
>>>> +socklen_t len = sizeof(cpu);
>>>> +setsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu, &len);
>>>> +.fi
>>>> +.in
>>>> +.sp
>>>> +The typical use case is one listener per RX queue, as the associated listener
>>>> +should only accept flows handled in softirq by the same cpu. This provides
>>>> +optimal NUMA behavior and keep cpu caches hot.
>>>> +.TP
>>>> .B SO_KEEPALIVE
>>>> Enable sending of keep-alive messages on connection-oriented sockets.
>>>> Expects an integer boolean flag.
>>>
>>> Thank you! Patch applied.
>>>
>>> I have tried to enhance the description somewhat. I'm not sure whether
>>> what I've written is quite correct (or whether it should be further
>>> extended). Eric, could you please take a look at the following, and let
>>> me know if anything needs fixing:
>>>
>>> SO_INCOMING_CPU (gettable since Linux 3.19, settable since Linux
>>> 4.4)
>>> Sets or gets the CPU affinity of a socket. Expects an
>>> integer flag.
>>>
>>> int cpu = 1;
>>> socklen_t len = sizeof(cpu);
>>> setsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu, &len);
>>>
>>> Because all of the packets for a single stream (i.e., all
>>> packets for the same 4-tuple) arrive on the single RX queue
>>> that is associated with a particular CPU, the typical use
>>> case is to employ one listening process per RX queue, with
>>> the incoming flow being handled by a listener on the same
>>> CPU that is handling the RX queue. This provides optimal
>>> NUMA behavior and keeps CPU caches hot.
> Hi Michael
>
> Sorry for the delay.
Thanks for the reply, but I think you are assuming I know more than
I do. I'd like you to elaborate a little please. See below.
> Note that setting the option is not supported if SO_REUSEPORT is used.
Please define "not supported". Does this yield an API diagnostic?
If so, what is it?
> Socket will be selected from an array, either by a hash or BPF program
> that has no access to this information.
Sorry -- I'm lost here. How does this comment relate to the proposed
man page text above?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" 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] netfilter: ctnetlink: Make some parameters integer to avoid enum mismatch
From: Matthias Kaehlcke @ 2017-04-19 18:39 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, David S . Miller
Cc: netfilter-devel, coreteam, netdev, linux-kernel, Grant Grundler,
Greg Hackmann, Michael Davidson, Matthias Kaehlcke
Not all parameters passed to ctnetlink_parse_tuple() and
ctnetlink_exp_dump_tuple() match the enum type in the signatures of these
functions. Since this is intended change the argument type of to be an int
value.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
net/netfilter/nf_conntrack_netlink.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index dc7dfd68fafe..775eb5d9165b 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -1006,9 +1006,8 @@ static const struct nla_policy tuple_nla_policy[CTA_TUPLE_MAX+1] = {
static int
ctnetlink_parse_tuple(const struct nlattr * const cda[],
- struct nf_conntrack_tuple *tuple,
- enum ctattr_type type, u_int8_t l3num,
- struct nf_conntrack_zone *zone)
+ struct nf_conntrack_tuple *tuple, u32 type,
+ u_int8_t l3num, struct nf_conntrack_zone *zone)
{
struct nlattr *tb[CTA_TUPLE_MAX+1];
int err;
@@ -2443,7 +2442,7 @@ static struct nfnl_ct_hook ctnetlink_glue_hook = {
static int ctnetlink_exp_dump_tuple(struct sk_buff *skb,
const struct nf_conntrack_tuple *tuple,
- enum ctattr_expect type)
+ u32 type)
{
struct nlattr *nest_parms;
--
2.12.2.816.g2cccc81164-goog
^ permalink raw reply related
* Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201
From: Aleksander Morgado @ 2017-04-19 18:32 UTC (permalink / raw)
To: Bjørn Mork
Cc: Daniele Palmas, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87efwob92t.fsf-3F4PFWf5pNjpjLOzFPqGjWGXanvQGlWp@public.gmane.org>
On Wed, Apr 19, 2017 at 7:28 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
>> as a side note in latest kernels I had troubles with qmi devices
>> (e.g. I/O error when using qmicli).
>>
>> I found your suggestion in libqmi mailing list to revert commit
>>
>> 833415a3e781a26fe480a34d45086bdb4fe1e4c0
>> cdc-wdm: fix "out-of-sync" due to missing notifications
>
> I guess a revert of that commit should be done then..
>
> I have been stalling because I have been hoping to replace it with a
> better fix instead of a plain revert. I believe there are several issues
> playing badly together here. That commit was _expected_ to cause
> spurious EPIPE errors, which would be translated to EIO if they were
> propagated. But they should be filtered out rightaway, in theory. This
> works for me. I can see the EPIPEs with debugging, but I have never
> seen any EIO from read.
>
> And there is the problem: I am unable to reproduce this problem. I have
> previously tested this back and forth with several MDM9200 and MDM9235
> generation modems in QMI mode, as well as in MBIM mode. And also with a
> number of other MBIM modems. Aleksander reported that he could
> reproduce the issue using an MDM9x15 generation modem in QMI mode, but
> not with any MDM9x00 or MDM9x35 modem. So I have now tried any way I
> can imagine to reproduce the issue with a Sierra Wireless EM7305, which
> is the only MDM9x15 modem I have. The firmware is SWI9X15C_05.05.58.00.
>
> But unfortunately the testing is still without "success". It plain
> works for me, every time, using ModemManager, qmicli with or without
> proxy, or uqmi.
>
> Would you mind describing in detail how you trigger the EIOs? What
> software and command sequence are you using? Does it reliably reproduce
> the issue, or do you have to try several times? What modem chipset and
> firmware is used?
Reliably, as in the second command I sent already showed the issue :/
I meant to try to debug this issue myself a while ago, but got busy
with other stuff, as usual... This is with a Sierra Wireless MC7304
running SWI9X15C_05.05.67.00. If you want, I can give you SSH access
to a system with this modem plugged in, or I can even send you a spare
MC7354, whatever you prefer.
I'm just running --dms-get-operating-mode multiple times, and getting
errors frequently:
aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'
aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[19 abr 2017, 20:25:36] -Warning ** Error reading from istream: Error
reading from file descriptor: Input/output error
^[[A^Ccancelling the operation...
error: couldn't create client for the 'dms' service: Operation was cancelled
aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[19 abr 2017, 20:25:38] -Warning ** Error reading from istream: Error
reading from file descriptor: Input/output error
^Ccancelling the operation...
error: couldn't create client for the 'dms' service: Operation was cancelled
aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'
aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'
aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'
aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'
aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[19 abr 2017, 20:25:52] -Warning ** Error reading from istream: Error
reading from file descriptor: Input/output error
error: couldn't create client for the 'dms' service: CID allocation
failed in the CTL client: Transaction timed out
...
--
Aleksander
https://aleksander.es
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [RFC PATCH net] net/mlx5e: Race between mlx5e_update_stats() and getting the stats
From: Martin KaFai Lau @ 2017-04-19 18:29 UTC (permalink / raw)
To: netdev; +Cc: Saeed Mahameed, kernel-team
We have observed a sudden spike in rx/tx_packets and rx/tx_bytes
reported under /proc/net/dev. It seems there is a race in
mlx5e_update_stats() and some of the get-stats functions (the
one that we hit is the mlx5e_get_stats() which is called
by ndo_get_stats64()).
In particular, the very first thing mlx5e_update_sw_counters()
does is 'memset(s, 0, sizeof(*s))'. For example, if mlx5e_get_stats()
is unlucky at one point, rx_bytes and rx_packets could be 0. One second
later, a normal (and much bigger than 0) value will be reported.
This patch is not meant to be a proper fix. It merely tries
to show what I have suspected and start the discussion.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Cc: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 7 +++++--
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 3 +++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
index a004a5a1a4c2..d24916f720bb 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -313,7 +313,6 @@ static void mlx5e_get_ethtool_stats(struct net_device *dev,
mutex_lock(&priv->state_lock);
if (test_bit(MLX5E_STATE_OPENED, &priv->state))
mlx5e_update_stats(priv);
- mutex_unlock(&priv->state_lock);
for (i = 0; i < NUM_SW_COUNTERS; i++)
data[idx++] = MLX5E_READ_CTR64_CPU(&priv->stats.sw,
@@ -378,8 +377,10 @@ static void mlx5e_get_ethtool_stats(struct net_device *dev,
data[idx++] = MLX5E_READ_CTR64_CPU(mlx5_priv->pme_stats.error_counters,
mlx5e_pme_error_desc, i);
- if (!test_bit(MLX5E_STATE_OPENED, &priv->state))
+ if (!test_bit(MLX5E_STATE_OPENED, &priv->state)) {
+ mutex_unlock(&priv->state_lock);
return;
+ }
/* per channel counters */
for (i = 0; i < priv->params.num_channels; i++)
@@ -393,6 +394,8 @@ static void mlx5e_get_ethtool_stats(struct net_device *dev,
for (j = 0; j < NUM_SQ_STATS; j++)
data[idx++] = MLX5E_READ_CTR64_CPU(&priv->channel[i]->sq[tc].stats,
sq_stats_desc, j);
+
+ mutex_unlock(&priv->state_lock);
}
static u32 mlx5e_rx_wqes_to_packets(struct mlx5e_priv *priv, int rq_wq_type,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 66c133757a5e..a4c100bea541 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -2748,6 +2748,8 @@ mlx5e_get_stats(struct net_device *dev, struct rtnl_link_stats64 *stats)
struct mlx5e_vport_stats *vstats = &priv->stats.vport;
struct mlx5e_pport_stats *pstats = &priv->stats.pport;
+ mutex_lock(&priv->state_lock);
+
if (mlx5e_is_uplink_rep(priv)) {
stats->rx_packets = PPORT_802_3_GET(pstats, a_frames_received_ok);
stats->rx_bytes = PPORT_802_3_GET(pstats, a_octets_received_ok);
@@ -2783,6 +2785,7 @@ mlx5e_get_stats(struct net_device *dev, struct rtnl_link_stats64 *stats)
stats->multicast =
VPORT_COUNTER_GET(vstats, received_eth_multicast.packets);
+ mutex_unlock(&priv->state_lock);
}
static void mlx5e_set_rx_mode(struct net_device *dev)
--
2.9.3
^ permalink raw reply related
* [PATCH net] gso: Validate assumption of frag_list segementation
From: ilant @ 2017-04-19 18:26 UTC (permalink / raw)
To: David Miller
Cc: netdev, Alexander Duyck, Eric Dumazet, Steffen Klassert,
Boris Pismenny, Ilya Lesokhin, Ilan Tayari
From: Ilan Tayari <ilant@mellanox.com>
Commit 07b26c9454a2 ("gso: Support partial splitting at the frag_list
pointer") assumes that all SKBs in a frag_list (except maybe the last
one) contain the same amount of GSO payload.
This assumption is not always correct, resulting in the following
warning message in the log:
skb_segment: too many frags
For example, mlx5 driver in Striding RQ mode creates some RX SKBs with
one frag, and some with 2 frags.
After GRO, the frag_list SKBs end up having different amounts of payload.
If this frag_list SKB is then forwarded, the aforementioned assumption
is violated.
Validate the assumption, and fall back to software GSO if it not true.
Change-Id: Ia03983f4a47b6534dd987d7a2aad96d54d46d212
Fixes: 07b26c9454a2 ("gso: Support partial splitting at the frag_list pointer")
Signed-off-by: Ilan Tayari <ilant@mellanox.com>
Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
---
net/core/skbuff.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 35c1e2460206..f86bf69cfb8d 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3082,22 +3082,32 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
if (sg && csum && (mss != GSO_BY_FRAGS)) {
if (!(features & NETIF_F_GSO_PARTIAL)) {
struct sk_buff *iter;
+ unsigned int frag_len;
if (!list_skb ||
!net_gso_ok(features, skb_shinfo(head_skb)->gso_type))
goto normal;
- /* Split the buffer at the frag_list pointer.
- * This is based on the assumption that all
- * buffers in the chain excluding the last
- * containing the same amount of data.
+ /* If we get here then all the required
+ * GSO features except frag_list are supported.
+ * Try to split the SKB to multiple GSO SKBs
+ * with no frag_list.
+ * Currently we can do that only when the buffers don't
+ * have a linear part and all the buffers except
+ * the last are of the same length.
*/
+ frag_len = list_skb->len;
skb_walk_frags(head_skb, iter) {
+ if (frag_len != iter->len && iter->next)
+ goto normal;
if (skb_headlen(iter))
goto normal;
len -= iter->len;
}
+
+ if (len != frag_len)
+ goto normal;
}
/* GSO partial only requires that we trim off any excess that
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] net: arc_emac: switch to phy_start()/phy_stop()
From: Sergei Shtylyov @ 2017-04-19 18:22 UTC (permalink / raw)
To: Alexander Kochetkov, David S. Miller, Philippe Reynes, Peter Chen,
Wei Yongjun, netdev, linux-kernel
In-Reply-To: <1492612195-16601-1-git-send-email-al.kochet@gmail.com>
On 04/19/2017 05:29 PM, Alexander Kochetkov wrote:
> The patch replace phy_start_aneg() with phy_start(). phy_start() call
Replaces.
> phy_start_aneg() as a part of startup sequence and allow recover from
> error (PHY_HALTED) state.
>
> Also added call phy_stop() to arc_emac_remove() to stop PHY state machine
To arc_emac_stop() maybe?
> when MAC is down.
> Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
> ---
> drivers/net/ethernet/arc/emac_main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
> index abc9f2a..188676d 100644
> --- a/drivers/net/ethernet/arc/emac_main.c
> +++ b/drivers/net/ethernet/arc/emac_main.c
[...]
> @@ -556,6 +556,8 @@ static int arc_emac_stop(struct net_device *ndev)
> napi_disable(&priv->napi);
> netif_stop_queue(ndev);
>
> + phy_stop(ndev->phydev);
> +
> /* Disable interrupts */
> arc_reg_clr(priv, R_ENABLE, RXINT_MASK | TXINT_MASK | ERR_MASK);
>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] net: phy: fix auto-negotiation stall due to unavailable interrupt
From: Sergei Shtylyov @ 2017-04-19 18:11 UTC (permalink / raw)
To: Alexander Kochetkov, Florian Fainelli, netdev, linux-kernel
In-Reply-To: <1492609604-16359-1-git-send-email-al.kochet@gmail.com>
Hello!
On 04/19/2017 04:46 PM, Alexander Kochetkov wrote:
> The problem I fix related to SMSC LAN8710/LAN8720 PHY handled using
> interrupts. During power-up cycle the PHY do auto-negotiation, generate
> interrupt and set BMSR_ANEGCOMPLETE flag. Interrupt is handled by PHY
> state machine but doesn't update link because PHY is in PHY_READY state.
> After some time MAC bring up and connect with PHY. It start PHY using
> phy_start(). During startup PHY change state to PHY_AN but doesn't
> set BMCR_ANRESTART flag due to genphy_config_aneg() doesn't update MII_BMCR
> because there no new to advertising. As a result, state machine wait for
^^^^^^^^^^^^ ^^^^^^^^^^^
There is no new what? Advertize, maybe?
> interrupt from PHY and nether get "link is up". Because BMSR_ANEGCOMPLETE
^^^^^^
Never, neither? :-)
> already set the patch schedule check link without waiting interrupt.
> In case genphy_config_aneg() update MII_BMCR and set BMCR_ANRESTART
> flag, BMSR_ANEGCOMPLETE will be cleared and state machine will continue
> on auto-negotiation interrupt.
>
> Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: bluetooth 6lowpan interfaces are not virtual anymore
From: Alexander Aring @ 2017-04-19 18:01 UTC (permalink / raw)
To: Michael Richardson
Cc: Network Development, Jukka Rissanen, Luiz Augusto von Dentz,
linux-wpan-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Bluetooth
In-Reply-To: <28530.1492534783-FKvY79KaN4jY2Mpo3neBCSwD8/FfD2ys@public.gmane.org>
Hi Michael,
On 04/18/2017 06:59 PM, Michael Richardson wrote:
>
> Alexander Aring <aar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> > What does the 6LoWPAN interface?
>
> > It will do a protocol change (an adaptation, because 6LoWPAN should
> > provide the same functionality as IPv6) from IPv6 to 6LoWPAN (tx) and
> > vice versa for (rx). In my opinion this should be handled as a virtual
> > interface and not as an interface with a queue.
>
> I wonder if modeling all the 6lowpan work as a virtual interface is even
> the right abstraction anymore. I think that it was certainly a good model at
> the time the interface was created, given no other clear thing to do.
>
> We don't model IPv6 ND (or IPv4 ARP) or fragmentation in general as a
> virtual interface on top of a raw interface.
>
> Really, it's a set of operations that happens on a packet.
> 802.15.4 is notable for it's current lack of an ethertype (IEEE is fixing
> that though), so you can't actually run different protocols on the
> same PANID.
> BT does have a variety of different protocols, and IPv6 is only one.
>
> In a classic SVR4 STREAMS works, it would have been just another module.
> (No, I'm not a fan of *STREAMS* or of SVR4 in general, although I liked
> some of the ideas).
>
ok, I see you complain about "having a virtual on top of wpan
interface", or?
I wanted to talk at first about the queue handling which is introduced
when 6LoWPAN is not a virtual interface anymore. Or do you want to have
a queue in front of 6lowpan adaptation (see other mail reply with ASCII
graphics).
My definition of virtual interfaces:
- Virtual interfaces: has no queue.
- Non Virtual interfaces: has queue(s).
> At this time, things like PANID and channel are set on the wpanX interface.
> If they were set on the 6lowpan interface, such that one could (in theory,
> assuming the hardware could do it, which some can, and some can not) then
> one could have multiple 6lowpan interfaces on top of the same wpanX.
> Or one could run some non-IP protocol like pre-IP Zigbee on one PANID
> while one runs 6lowpan on another. THEN, a virtual interface would make
> sense for the same reason VLAN interfaces make sense.
>
We can change that you can run multiple interfaces on one PHY. Currently
we just allow one, because address filtering. Disable address filtering
-> we will loose ACK handling on hardware.
I can try to implement all stuff in software "for fun, maybe see what we
can do to handle ACK in software, etc" Then you can run multiple wpan
interfaces on different "source PANID". Then we need some additonal
parameter for creating 6lowpan interfaces in case of 802.15.4 to add a
destination PANID. Last one should not big deal, because this doesn't
require to turn address filtering off.
One question would be:
It's fine to have it as _per_ interface setting or do you want to have
that on sendmsg(2) level?
---
You complain also, maybe... because currently it's hard to deal with
configuration 6lowpan interfaces with 802.15.4 interfaces. Because you
need to have both down to change address filtering etc.
What we can do there is "make it easier" if wpan interface goes down,
then upper 6LoWPAN interface goes also down (we can do that). But here
is the question - a userspace programm can do the same job.
For setting channels/panid for 6lowpan interfaces -> we can make that
nl802154 will also accept net_device namens for 802.15.4 6lowpan
interfaces which makes changes to the "lower" wpan interface -> should
be possible.
Let me known if you like to have such solution, which should make it
just simpler to dealing with ifdown/ifup and changing interface naming
stuff.
Currently, we forbid much stuff - We can do some changes (tx parameters)
when interface is up, just need to besure we don't changes paramters
while transmit. But make everything at first forbidden and then allows
more will usally not break UAPI. :-)
- Alex
^ permalink raw reply
* Re: [PATCH v4 net-next RFC] net: Generic XDP
From: John Fastabend @ 2017-04-19 17:44 UTC (permalink / raw)
To: Alexei Starovoitov, Andy Gospodarek
Cc: David Miller, michael.chan, netdev, xdp-newbies
In-Reply-To: <20170419171753.GA12838@ast-mbp.thefacebook.com>
On 17-04-19 10:17 AM, Alexei Starovoitov wrote:
> On Wed, Apr 19, 2017 at 10:29:03AM -0400, Andy Gospodarek wrote:
>>
>> I ran this on top of a card that uses the bnxt_en driver on a desktop
>> class system with an i7-6700 CPU @ 3.40GHz, sending a single stream of
>> UDP traffic with flow control disabled and saw the following (all stats
>> in Million PPS).
>>
>> xdp1 xdp2 xdp_tx_tunnel
>> Generic XDP 7.8 5.5 (1.3 actual) 4.6 (1.1 actual)
>> Optimized XDP 11.7 9.7 4.6
>
> Nice! Thanks for testing.
>
>> One thing to note is that the Generic XDP case shows some different
>> results for reported by the application vs actual (seen on the wire). I
>> did not debug where the drops are happening and what counter needs to be
>> incremented to note this -- I'll add that to my TODO list. The
>> Optimized XDP case does not have a difference in reported vs actual
>> frames on the wire.
>
> The missed packets are probably due to xmit queue being full.
> We need 'xdp_tx_full' counter in:
> + if (free_skb) {
> + trace_xdp_exception(dev, xdp_prog, XDP_TX);
> + kfree_skb(skb);
> + }
> like in-driver xdp does.
> It's surprising that tx becomes full so often. May be bnxt specific behavior?
hmm as a data point I get better numbers than 1.3Mpps running through the qdisc
layer with pktgen so seems like something is wrong with the driver perhaps? If
I get a chance I'll take a look with my setup here, although it likely wont be
until the weekend. I don't think it needs to slow down dropping the RFC tag
and getting the patch applied though.
>
>> I agree with all those who have asserted that this is great tool for
>> those that want to get started with XDP but do not have hardware, so I'd
>> say it's ready to have the 'RFC' tag dropped. Thanks for pushing this
>> forward, Dave! :-)
>
> +1
>
>
^ permalink raw reply
* Re: bluetooth 6lowpan interfaces are not virtual anymore
From: Alexander Aring @ 2017-04-19 17:43 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Network Development, Jukka Rissanen,
linux-wpan-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Bluetooth, Michael Richardson
In-Reply-To: <CABBYNZLqTvd5cnG4fKJgPKJGvS6hsk8vOM+7NQ_RhLJ-WOszmg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
at first I want to clarify what my definition of virtual and non virtual
interface is:
- virtual interfaces: has no queue(s)
- non virtual interfaces: has a queue(s)
I did some "big" ASCII graphic what I think it will do now.
At first the virtual interface:
--- snip ---
Transmit side only! Case of virtual interface.
IPv6 Stack
+-----------------------------+
| IPv6 Packet (ND, etc) |
+--------------+--------------+
|
-------------------------+---------------------------------
6LoWPAN Interface |
|
+--------------v--------------+
| Adaptation (IPv6 to 6Lo) |
+--------------+--------------+
+--------------------------+
|
| -----------------------------------------------------------
Link|Layer (802.15.4/hci_dev/etc)
|
| SKB Queue (With kind of discipline)
| +----------------+---------------+-------------+
+-----------> SKB1 | SKBN | ... +----+
+----------------+---------------+-------------+ |
|
|
------------------------------------------------------------ |
Real Transeiver Hardware |
+----------------------------+
|
+------------------------v-----------------------+
| Framebuffers (YOUR hardware resource) |
+------------------------------------------------+
--- snap ---
The non virtual interface:
--- snip ---
Transmit side only! Case of non virtual interface.
IPv6 Stack
+-----------------------------+
| IPv6 Packet (ND, etc) |
+--------------+--------------+
|
-------------------------+---------------------------------
6LoWPAN Interface |
|
+--------------------------+
| /> Will be queued if you stop the queue
| SKB Queue (With kind of discipline) /-- Because Link Layer is full/software limitation
| +----------------+---------------+-------------+
+-----------> SKB1 | SKBN | ... +----+
+----------------+---------------+-------------+ |
|
+------------------------------------+
|
+--------------v--------------+
| Adaptation (IPv6 to 6Lo) |
+--------------+--------------+
+--------------------------+
|
| -----------------------------------------------------------
Link|Layer (802.15.4/hci_dev/etc)
| -> software limitation (tx credits?)
| SKB Queue (With kind of discipline) ---/ Right position to make different handling (for virtual case).
| +----------------+---------------+------------/+
+-----------> SKB1 | SKBN | ... +----+
+----------------+---------------+-------------+ |
|
|
------------------------------------------------------------ |
Real Transeiver Hardware |
+----------------------------+
|
+------------------------v-----------------------+
| Framebuffers (YOUR hardware resource) |
+------------------------------------------------+
--- snap ---
Adding a queue to a interface which does a protocol translation only is
in my opinion: wrong.
At least if you want to try to make a more efficient qdisc handling,
means dropping skb's in queue when userspace sends too much. You will
change it back, control two queues seems to be difficult.
On 04/18/2017 12:43 PM, Luiz Augusto von Dentz wrote:
> Hi Alex,
>
> On Mon, Apr 17, 2017 at 8:56 PM, Alexander Aring <aar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
>> Hi,
>>
>> bluetooth-next contains patches which introduces a queue for bluetooth
>> 6LoWPAN interfaces. [0]
>>
>> At first, the current behaviour is now that 802.15.4 6LoWPAN interfaces
>> are virtual and bluetooth 6LoWPAN interfaces are not virtual anymore.
>> To have a different handling in both subsystems is _definitely_ wrong.
>
> Well 15.4 and Bluetooth have very different handling, iirc in 15.4 you
> do have a real interface which has, in fact, queueing support:
>
> net/mac802154/iface.c:ieee802154_if_setup:
> dev->tx_queue_len = 300;
>
Is l2cap_chan_send a call with is synchronized which wait for it so
after that the "l2cap bluetooth *frame*. etc." is send?
I looked at the code [0]. It will queue it in some skb queue, so far I
see. Hard to see it in this code, but I see some queueing and workqueue
scheduling [1] in the function which will be called by l2cap_chan_send.
This queue should have the same meaning like our queue in IEEE
802.15.4 interface which you mentioned above.
At this point, we have no difference. There exists already a queue for
your real transeiver hardware.
>> What does the 6LoWPAN interface?
>>
>> It will do a protocol change (an adaptation, because 6LoWPAN should
>> provide the same functionality as IPv6) from IPv6 to 6LoWPAN (tx) and
>> vice versa for (rx). In my opinion this should be handled as a virtual
>> interface and not as an interface with a queue.
>
> Then we need a real netif for Bluetooth as well, one that does
> queueing since introducing for l2cap_chan makes no sense when most of
> time the userspace has a socket which does its own queueing. Btw, I
> have the opinion that doing a second interface just to make Bluetooth
> behave like 15.4 is very wasteful since we don't have any other
> network support except for bnep, which in fact does the same thing
> regarding queueing.
>
If bnep just generates some ethernet frames and you put L2CAP around,
then it should be virtual too. If it queue skbs for sending out for the
hci_dev. Then it ends in a similar queue handling like "non virtual
6LoWPAN interface".
What you mean with second interface? At least you need a capable
net_device interface to offer an IP connection from userspace.
>> What makes a queue on 6LoWPAN interfaces?
>>
>> It will queue IPv6 packets which waits for it adaptation (the protocol
>> change) with some additional qdisc handling.
>> If finally the xmit_do callback will occur it will replace IPv6 header
>> with 6LoWPAN, etc. After that it should be queued into some queue on
>> link layer side which should be do the transmit finally.
>
> In case of Bluetooth it does the Link Layer using L2CAP, which is not
> exactly at Link Layer, in fact it is one of the major problems of
> having this in Kernel space since it is similar of doing IP over TCP
> tunnel.
>
aha, but this has nothing to do to decide that you have a 6LoWPAN queue,
or? I think this is one reason why you want a "6lowtun" interface. To
handle L2CAP in userspace.
>> Why I think bluetooth introduced a queue handling on 6LoWPAN interfaces?
>>
>> Because I think they don't like their own *qdisc* handling on their link
>> layer interface. I write *qdisc* here because, they have no net_devices
>> and use some kind of own qdisc handling.
>
> No we don't, and except we do change the whole architecture of
> Bluetooth to work as a net_device I don't think we can have a similar
> design as 15.4. Anyway Bluetooth is not really designed to carry IP,
> the L2CAP and other profiles above are mostly a Bluetooth thing so
> having a net_device would not buy us much more than queueing for bnep
> and ipsp.
>
At least, having a queue and don't put anything anymore into the queue
when "tx credits" is at zero (because queue is full). _Is_ a kind of
qdisc handling.
>> My question: is this correct?
>>
>> How to fix that (In my opinion):
>>
>> So commit [0] says something "out of credits" that's what I think it's
>> the *qdisc* handling. If you cannot queue anymore -> you need to drop
>> it. If you don't like how the current behaviour is, you need to change
>> your *qdisc* handling on your link layer interface. Introducing queue at
>> 6LoWPAN interfaces will introduce "buffer bloating".
>
> That is not what the code comments says, eg. netif_stop_queue:
>
> * Stop upper layers calling the device hard_start_xmit routine.
> * Used for flow control when transmit resources are unavailable.
>
This comments are correct so long you operate on "real hardware
resources" which 6LoWPAN interfaces doesn't do. In case so far I see, it
will call l2cap_chan_send which putting some L2CAP protocol on it (to
provide data) and somewhere queue it for transmit to fill "real hardware
resources" e.g. framebuffers.
Your "resource" which is unavailable is the link layer queue, but this
is just a software limitation by bluetooth, which you can change by
software to make a different handling, than just adding more software queues.
What _virtual_ 6LoWPAN interface does is:
Input: IPv6 -> Output: 6LoWPAN, without any queueing in front of that.
> The fact 15.4, and bnep, uses these APIs makes me believe this is the
> proper way of using qdisc handling, the only difference here is at
> what level we would be using them.
>
On 15.4 we use it for link layer interface queue, but we don't put
another queue in 6LoWPAN. See my aboves ASCII arts which shows the
different when 6LoWPAN is virtual and not virtual.
---
We have already qdisc problems in our case. In 15.4 it "just works" for
now, but we need more handling there to send not garbage if one frame
gets dropped there, see [2].
In my opinion, if bluetooth people will hit similar issues, you will
change it back that 6LoWPAN has no queue anymore. Otherwise it will very
hard to decide which skbs you drop or not - because you need to deal
with two queues.
To make 6LoWPAN non virtual anymore and just adding a queue will occur
that you don't drop much anymore... but the queue at link layer
(hci_dev) will work as before and this occurs buffer bloating only.
>> ---
>>
>> I don't care what bluetooth does with the 6LoWPAN interface. If bluetooth
>> people wants such behaviour, then I am okay with that.
>>
>> I will bookmark this mail for the time when somebody reverts it to a
>> virtual interface again. I think somebody will change it again, or maybe
>> somebody will argument why we need a queue here.
>
> From what I could grasp from the code except if 6LoWPAN start creating
> its own interface, which it doesn't currently, it should never assume
> any specific behavior for an interface. 6LoWPAN right now only have
> helper functions which the interface code call on TX/RX, and by
> looking at code under 15.4 the only thing we would be doing is to set
> skb->dev = wdev; (wdev being the real device) as Bluetooth don't use
> 6lowpan fragmentation.
>
yep, there is a lot of work do make a better framework, but has nothing
do to why bluetooth introduced a second queue on 6lowpan interfaces.
> Btw, another big different in terms of design that it seems 15.4 does
> create interfaces to each and every link, in Bluetooth the interface
> is per adapter so it is in fact multi-link, I guess in practice 15.4
> shall only have one 6lowpan link since it is connected to mesh, but in
> Bluetooth we may have more than one Link and I don't think it would be
> a good idea to have each of these links as a different interface,
> especially not with the same mac address as it seems to be what 15.4
> code is doing:
>
> /* Set the lowpan hardware address to the wpan hardware address. */
> memcpy(ldev->dev_addr, wdev->dev_addr, IEEE802154_ADDR_LEN);
>
Of course we need the same mac address there (at first), because we
have an address filter on hardware.
(Be aware that you _cannot_ change the mac address (dev->dev_addr) while IP
capable net device is up. They assume the mac address is read only if net
device is up.)
There is currently an idea to provide multiple links, but then hardware
need to go into promiscuous mode (disable address filtering) but then we
will lose some hardware offloading stuff e.g. ACK handling.
If we have that, we can provide multiple links with different mac
addresses, at least this will be handled as multiple wpan interfaces for
one PHY.
> So at least with IPSP/RFC-7668 the topology is completely different
> from what we can see in 15.4, it may happen that this changes with
> upcoming changes to Bluetooth, adding yet another topology that we
> will need to support. Personally I wouldn't mind if 15.4 and Bluetooth
> had more in common, at least at 6lowpan level, so we wouldn't have the
> need to create separated modules just to deal with their differences,
> but in reality, these technologies are competing for the same market
> so I don't think it will happen, unfortunately.
>
You already have separated modules, this is .e.g IPHC stuff and 6lowpan
specific implementation for bluetooth. In net/bluetooth/6lowpan.c you
can put your changes for make specific bluetooth handling.
This discussion moved currently to a more complex question about how to
make the whole 6lowpan architecture...
I think I tried to explain so much as possible what a queue on top of
6lowpan interface will do, at least if you want to make a better queue
handling (when dropping skb's inside the queue(s)) then you will fail
and revert that change (I think). But then I can say "I told you so" :-)
- Alex
[0] http://lxr.free-electrons.com/source/net/bluetooth/l2cap_core.c#L2455
[1] http://lxr.free-electrons.com/source/net/bluetooth/hci_core.c#L3490
[2] http://www.spinics.net/lists/linux-wpan/msg03679.html
^ permalink raw reply
* [PATCH] ieee802154: don't select COMMON_CLK
From: Arnd Bergmann @ 2017-04-19 17:32 UTC (permalink / raw)
To: Marcel Holtmann, Alexander Aring, Stefan Schmidt
Cc: Arnd Bergmann, Harry Morris, linux-wpan, netdev, linux-kernel
A device driver must not select the COMMON_CLK subsystem, as that conflicts
with platforms that provide a legacy implementation of the clk API:
drivers/clk/clk.o: In function `clk_enable':
clk.c:(.text.clk_enable+0x0): multiple definition of `clk_enable'
arch/arm/mach-sa1100/clock.o:clock.c:(.text.clk_enable+0x0): first defined here
drivers/clk/clk.o: In function `clk_round_rate':
clk.c:(.text.clk_round_rate+0x0): multiple definition of `clk_round_rate'
arch/arm/mach-sa1100/clock.o:clock.c:(.text.clk_round_rate+0x0): first defined here
drivers/clk/clk.o: In function `clk_get_parent':
clk.c:(.text.clk_get_parent+0x0): multiple definition of `clk_get_parent'
arch/arm/mach-sa1100/clock.o:clock.c:(.text.clk_get_parent+0x0): first defined here
drivers/clk/clk.o: In function `clk_get_rate':
clk.c:(.text.clk_get_rate+0x0): multiple definition of `clk_get_rate'
This changes the 'select' into 'depends on', as all other similar drivers do.
Fixes: d931acd575d6 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ieee802154/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/Kconfig b/drivers/net/ieee802154/Kconfig
index ce4864dc3c6e..303ba4133920 100644
--- a/drivers/net/ieee802154/Kconfig
+++ b/drivers/net/ieee802154/Kconfig
@@ -86,8 +86,8 @@ config IEEE802154_ADF7242
config IEEE802154_CA8210
tristate "Cascoda CA8210 transceiver driver"
depends on IEEE802154_DRIVERS && MAC802154
+ depends on COMMON_CLK
depends on SPI
- select COMMON_CLK
---help---
Say Y here to enable the CA8210 SPI 802.15.4 wireless
controller.
--
2.9.0
^ permalink raw reply related
* [PATCH net-next] liquidio: remove unnecessary variable assignment
From: Arnd Bergmann @ 2017-04-19 17:30 UTC (permalink / raw)
To: Derek Chickles, Satanand Burla, Felix Manlunas, Raghu Vatsavayi
Cc: Arnd Bergmann, David S. Miller, Prasad Kanneganti, netdev,
linux-kernel
gcc points out an useless assignment that was added during code refactoring:
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c: In function 'octnet_intrmod_callback':
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1315:59: error: parameter 'oct_dev' set but not used [-Werror=unused-but-set-parameter]
This is harmless but can clearly be remove to avoid the warning.
Fixes: 50c0add534d2 ("liquidio: refactor interrupt moderation code")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index dab10c7e4443..579dc7336f58 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -1323,8 +1323,6 @@ static void octnet_intrmod_callback(struct octeon_device *oct_dev,
ctx->status = status;
- oct_dev = lio_get_device(ctx->octeon_id);
-
WRITE_ONCE(ctx->cond, 1);
/* This barrier is required to be sure that the response has been
--
2.9.0
^ permalink raw reply related
* [PATCH net-next] i40evf: hide unused variable
From: Arnd Bergmann @ 2017-04-19 17:29 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Arnd Bergmann, Bimmy Pujari, Alexander Duyck, Mitch Williams,
Jacob Keller, Alan Brady, Joe Perches, Anjali Singhai Jain,
Jesse Brandeburg, Preethi Banala, intel-wired-lan, netdev,
linux-kernel
On architectures with larger pages, we get a warning about an unused variable:
drivers/net/ethernet/intel/i40evf/i40evf_main.c: In function 'i40evf_configure_rx':
drivers/net/ethernet/intel/i40evf/i40evf_main.c:690:21: error: unused variable 'netdev' [-Werror=unused-variable]
This moves the declaration into the #ifdef to avoid the warning.
Fixes: dab86afdbbd1 ("i40e/i40evf: Change the way we limit the maximum frame size for Rx")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 12a930e879af..1bb13c864edd 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -687,13 +687,14 @@ static void i40evf_configure_tx(struct i40evf_adapter *adapter)
static void i40evf_configure_rx(struct i40evf_adapter *adapter)
{
unsigned int rx_buf_len = I40E_RXBUFFER_2048;
- struct net_device *netdev = adapter->netdev;
struct i40e_hw *hw = &adapter->hw;
int i;
/* Legacy Rx will always default to a 2048 buffer size. */
#if (PAGE_SIZE < 8192)
if (!(adapter->flags & I40EVF_FLAG_LEGACY_RX)) {
+ struct net_device *netdev = adapter->netdev;
+
/* For jumbo frames on systems with 4K pages we have to use
* an order 1 page, so we might as well increase the size
* of our Rx buffer to make better use of the available space
--
2.9.0
^ permalink raw reply related
* Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201
From: Bjørn Mork @ 2017-04-19 17:28 UTC (permalink / raw)
To: Daniele Palmas; +Cc: netdev, linux-usb, Aleksander Morgado
In-Reply-To: <1491838463-20299-1-git-send-email-dnlplm@gmail.com>
Daniele Palmas <dnlplm@gmail.com> writes:
> as a side note in latest kernels I had troubles with qmi devices
> (e.g. I/O error when using qmicli).
>
> I found your suggestion in libqmi mailing list to revert commit
>
> 833415a3e781a26fe480a34d45086bdb4fe1e4c0
> cdc-wdm: fix "out-of-sync" due to missing notifications
I guess a revert of that commit should be done then..
I have been stalling because I have been hoping to replace it with a
better fix instead of a plain revert. I believe there are several issues
playing badly together here. That commit was _expected_ to cause
spurious EPIPE errors, which would be translated to EIO if they were
propagated. But they should be filtered out rightaway, in theory. This
works for me. I can see the EPIPEs with debugging, but I have never
seen any EIO from read.
And there is the problem: I am unable to reproduce this problem. I have
previously tested this back and forth with several MDM9200 and MDM9235
generation modems in QMI mode, as well as in MBIM mode. And also with a
number of other MBIM modems. Aleksander reported that he could
reproduce the issue using an MDM9x15 generation modem in QMI mode, but
not with any MDM9x00 or MDM9x35 modem. So I have now tried any way I
can imagine to reproduce the issue with a Sierra Wireless EM7305, which
is the only MDM9x15 modem I have. The firmware is SWI9X15C_05.05.58.00.
But unfortunately the testing is still without "success". It plain
works for me, every time, using ModemManager, qmicli with or without
proxy, or uqmi.
Would you mind describing in detail how you trigger the EIOs? What
software and command sequence are you using? Does it reliably reproduce
the issue, or do you have to try several times? What modem chipset and
firmware is used?
Bjørn
^ permalink raw reply
* Re: [PATCH v2 net 2/2] net sched actions: decrement module refcount earlier
From: Cong Wang @ 2017-04-19 17:25 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Wolfgang Bumiller, Linux Kernel Network Developers,
David S. Miller
In-Reply-To: <861dba23-1244-ee57-a980-a6dceffa2793@mojatatu.com>
On Wed, Apr 19, 2017 at 4:32 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> This solves one issue, but I am afraid the issue Cong mentioned is a
> possibility still.
> Lets say user did a replace and tried to also replace the cookie
> in that transaction. The init() succeeds but the cookie allocation
> fails. To be correct we'll have to undo the replace i.e something
> like uninit() which will restore back the old values.
> This is very complex and unnecessary.
It is not complex once we move to RCU completely, replacement
is merely a pointer assignment, rollback is same.
It is necessary too according to the rules of RCU, as I said before, the
current code is broken, we can't modify an existing action with RCU,
we have to make a copy. I do have plan to make actions truly RCU,
but I have to redesign the action API's first.
^ permalink raw reply
* Re: [PATCH] xen/9pfs: select CONFIG_XEN_XENBUS_FRONTEND
From: Stefano Stabellini @ 2017-04-19 17:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Juergen Gross, Stefano Stabellini, boris.ostrovsky, groug,
xen-devel, Eric Van Hensbergen, Ron Minnich, Latchesar Ionkov,
David S. Miller, Stefano Stabellini, v9fs-developer, netdev,
linux-kernel
In-Reply-To: <20170419170648.3041204-1-arnd@arndb.de>
On Wed, 19 Apr 2017, Arnd Bergmann wrote:
> All Xen frontends need to select this symbol to avoid a link error:
>
> net/built-in.o: In function `p9_trans_xen_init':
> :(.text+0x149e9c): undefined reference to `__xenbus_register_frontend'
>
> Fixes: d4b40a02f837 ("xen/9pfs: build 9pfs Xen transport driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thank you for the fix!
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> net/9p/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/9p/Kconfig b/net/9p/Kconfig
> index 3f286f1bd1d3..e6014e0e51f7 100644
> --- a/net/9p/Kconfig
> +++ b/net/9p/Kconfig
> @@ -24,6 +24,7 @@ config NET_9P_VIRTIO
>
> config NET_9P_XEN
> depends on XEN
> + select XEN_XENBUS_FRONTEND
> tristate "9P Xen Transport"
> help
> This builds support for a transport for 9pfs between
> --
> 2.9.0
>
^ permalink raw reply
* Re: [PATCH v4 net-next RFC] net: Generic XDP
From: Alexei Starovoitov @ 2017-04-19 17:17 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: David Miller, michael.chan, netdev, xdp-newbies
In-Reply-To: <20170419142903.GJ4730@C02RW35GFVH8.dhcp.broadcom.net>
On Wed, Apr 19, 2017 at 10:29:03AM -0400, Andy Gospodarek wrote:
>
> I ran this on top of a card that uses the bnxt_en driver on a desktop
> class system with an i7-6700 CPU @ 3.40GHz, sending a single stream of
> UDP traffic with flow control disabled and saw the following (all stats
> in Million PPS).
>
> xdp1 xdp2 xdp_tx_tunnel
> Generic XDP 7.8 5.5 (1.3 actual) 4.6 (1.1 actual)
> Optimized XDP 11.7 9.7 4.6
Nice! Thanks for testing.
> One thing to note is that the Generic XDP case shows some different
> results for reported by the application vs actual (seen on the wire). I
> did not debug where the drops are happening and what counter needs to be
> incremented to note this -- I'll add that to my TODO list. The
> Optimized XDP case does not have a difference in reported vs actual
> frames on the wire.
The missed packets are probably due to xmit queue being full.
We need 'xdp_tx_full' counter in:
+ if (free_skb) {
+ trace_xdp_exception(dev, xdp_prog, XDP_TX);
+ kfree_skb(skb);
+ }
like in-driver xdp does.
It's surprising that tx becomes full so often. May be bnxt specific behavior?
> I agree with all those who have asserted that this is great tool for
> those that want to get started with XDP but do not have hardware, so I'd
> say it's ready to have the 'RFC' tag dropped. Thanks for pushing this
> forward, Dave! :-)
+1
^ permalink raw reply
* [PATCH] xen/9pfs: select CONFIG_XEN_XENBUS_FRONTEND
From: Arnd Bergmann @ 2017-04-19 17:06 UTC (permalink / raw)
To: Juergen Gross
Cc: Latchesar Ionkov, Stefano Stabellini, Arnd Bergmann,
Eric Van Hensbergen, netdev, groug, linux-kernel,
Stefano Stabellini, v9fs-developer, Ron Minnich, xen-devel,
boris.ostrovsky, David S. Miller
All Xen frontends need to select this symbol to avoid a link error:
net/built-in.o: In function `p9_trans_xen_init':
:(.text+0x149e9c): undefined reference to `__xenbus_register_frontend'
Fixes: d4b40a02f837 ("xen/9pfs: build 9pfs Xen transport driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/9p/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/9p/Kconfig b/net/9p/Kconfig
index 3f286f1bd1d3..e6014e0e51f7 100644
--- a/net/9p/Kconfig
+++ b/net/9p/Kconfig
@@ -24,6 +24,7 @@ config NET_9P_VIRTIO
config NET_9P_XEN
depends on XEN
+ select XEN_XENBUS_FRONTEND
tristate "9P Xen Transport"
help
This builds support for a transport for 9pfs between
--
2.9.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* Re: [patch] socket.7: Document SO_INCOMING_CPU
From: Eric Dumazet @ 2017-04-19 17:05 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Francois Saint-Jacques, linux-man, netdev, Eric Dumazet
In-Reply-To: <9c754f31-8ace-03f2-97f3-81e29eb6d997@gmail.com>
On Wed, 2017-04-19 at 15:20 +0200, Michael Kerrisk (man-pages) wrote:
> Ping Eric!
>
> Would you have a chance to review the proposed text below, please.
>
> Thanks,
>
Hi Michael
Sorry for the delay.
Note that setting the option is not supported if SO_REUSEPORT is used.
Socket will be selected from an array, either by a hash or BPF program
that has no access to this information.
Thanks !
> Michael
>
> On 02/19/2017 09:55 PM, Michael Kerrisk (man-pages) wrote:
> > [CC += Eric, so that he might review]
> >
> > Hello Francois,
> >
> > On 02/18/2017 05:06 AM, Francois Saint-Jacques wrote:
> >> This socket option is undocumented. Applies on the latest version
> >> (man-pages-4.09-511).
> >>
> >> diff --git a/man7/socket.7 b/man7/socket.7
> >> index 3efd7a5d8..1a3ffa253 100644
> >> --- a/man7/socket.7
> >> +++ b/man7/socket.7
> >> @@ -490,6 +490,26 @@ flag on a socket
> >> operation.
> >> Expects an integer boolean flag.
> >> .TP
> >> +.BR SO_INCOMING_CPU " (getsockopt since Linux 3.19, setsockopt since
> >> Linux 4.4)"
> >> +.\" getsocktop 2c8c56e15df3d4c2af3d656e44feb18789f75837
> >> +.\" setsocktop 70da268b569d32a9fddeea85dc18043de9d89f89
> >> +Sets or gets the cpu affinity of a socket. Expects an integer flag.
> >> +.sp
> >> +.in +4n
> >> +.nf
> >> +int cpu = 1;
> >> +socklen_t len = sizeof(cpu);
> >> +setsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu, &len);
> >> +.fi
> >> +.in
> >> +.sp
> >> +The typical use case is one listener per RX queue, as the associated listener
> >> +should only accept flows handled in softirq by the same cpu. This provides
> >> +optimal NUMA behavior and keep cpu caches hot.
> >> +.TP
> >> .B SO_KEEPALIVE
> >> Enable sending of keep-alive messages on connection-oriented sockets.
> >> Expects an integer boolean flag.
> >
> > Thank you! Patch applied.
> >
> > I have tried to enhance the description somewhat. I'm not sure whether
> > what I've written is quite correct (or whether it should be further
> > extended). Eric, could you please take a look at the following, and let
> > me know if anything needs fixing:
> >
> > SO_INCOMING_CPU (gettable since Linux 3.19, settable since Linux
> > 4.4)
> > Sets or gets the CPU affinity of a socket. Expects an
> > integer flag.
> >
> > int cpu = 1;
> > socklen_t len = sizeof(cpu);
> > setsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu, &len);
> >
> > Because all of the packets for a single stream (i.e., all
> > packets for the same 4-tuple) arrive on the single RX queue
> > that is associated with a particular CPU, the typical use
> > case is to employ one listening process per RX queue, with
> > the incoming flow being handled by a listener on the same
> > CPU that is handling the RX queue. This provides optimal
> > NUMA behavior and keeps CPU caches hot.
> >
> > Cheers,
> >
> > Michael
> >
>
>
^ permalink raw reply
* [PATCH net 6/6] kaweth: use skb_cow_head() to deal with cloned skbs
From: Eric Dumazet @ 2017-04-19 16:59 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, James Hughes, Eric Dumazet, Eric Dumazet
In-Reply-To: <20170419165926.30631-1-edumazet@google.com>
We can use skb_cow_head() to properly deal with clones,
especially the ones coming from TCP stack that allow their head being
modified. This avoids a copy.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: James Hughes <james.hughes@raspberrypi.org>
---
drivers/net/usb/kaweth.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/usb/kaweth.c b/drivers/net/usb/kaweth.c
index 876f02f4945eafdc2fb5cfa0f9dcb54d9b498af4..2a2c3edb6bad0b3bd257c3a101d100ad3b00cc59 100644
--- a/drivers/net/usb/kaweth.c
+++ b/drivers/net/usb/kaweth.c
@@ -803,18 +803,12 @@ static netdev_tx_t kaweth_start_xmit(struct sk_buff *skb,
}
/* We now decide whether we can put our special header into the sk_buff */
- if (skb_cloned(skb) || skb_headroom(skb) < 2) {
- /* no such luck - we make our own */
- struct sk_buff *copied_skb;
- copied_skb = skb_copy_expand(skb, 2, 0, GFP_ATOMIC);
- dev_kfree_skb_irq(skb);
- skb = copied_skb;
- if (!copied_skb) {
- kaweth->stats.tx_errors++;
- netif_start_queue(net);
- spin_unlock_irq(&kaweth->device_lock);
- return NETDEV_TX_OK;
- }
+ if (skb_cow_head(skb, 2)) {
+ kaweth->stats.tx_errors++;
+ netif_start_queue(net);
+ spin_unlock_irq(&kaweth->device_lock);
+ dev_kfree_skb_any(skb);
+ return NETDEV_TX_OK;
}
private_header = (__le16 *)__skb_push(skb, 2);
--
2.12.2.816.g2cccc81164-goog
^ permalink raw reply related
* [PATCH net 2/6] cx82310_eth: use skb_cow_head() to deal with cloned skbs
From: Eric Dumazet @ 2017-04-19 16:59 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, James Hughes, Eric Dumazet, Eric Dumazet
In-Reply-To: <20170419165926.30631-1-edumazet@google.com>
We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.
skb_cow_head() is the proper helper to deal with this.
Fixes: cc28a20e77b2 ("introduce cx82310_eth: Conexant CX82310-based ADSL router USB ethernet driver")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: James Hughes <james.hughes@raspberrypi.org>
---
drivers/net/usb/cx82310_eth.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/cx82310_eth.c b/drivers/net/usb/cx82310_eth.c
index e221bfcee76b40a3ad7ba60ec4d348f4b8f4cc73..947bea81d924124c3827e87f75e732e35adb2acd 100644
--- a/drivers/net/usb/cx82310_eth.c
+++ b/drivers/net/usb/cx82310_eth.c
@@ -293,12 +293,9 @@ static struct sk_buff *cx82310_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
{
int len = skb->len;
- if (skb_headroom(skb) < 2) {
- struct sk_buff *skb2 = skb_copy_expand(skb, 2, 0, flags);
+ if (skb_cow_head(skb, 2)) {
dev_kfree_skb_any(skb);
- skb = skb2;
- if (!skb)
- return NULL;
+ return NULL;
}
skb_push(skb, 2);
--
2.12.2.816.g2cccc81164-goog
^ permalink raw reply related
* [PATCH net 4/6] lan78xx: use skb_cow_head() to deal with cloned skbs
From: Eric Dumazet @ 2017-04-19 16:59 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, James Hughes, Eric Dumazet, Eric Dumazet, Woojung Huh
In-Reply-To: <20170419165926.30631-1-edumazet@google.com>
We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.
skb_cow_head() is the proper helper to deal with this.
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: James Hughes <james.hughes@raspberrypi.org>
Cc: Woojung Huh <woojung.huh@microchip.com>
---
drivers/net/usb/lan78xx.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 9889a70ff4f6fece5bfabbfb45a3470f721a5a32..636f48f19d1eacae67c050de4fc3e651bffdf825 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2607,14 +2607,9 @@ static struct sk_buff *lan78xx_tx_prep(struct lan78xx_net *dev,
{
u32 tx_cmd_a, tx_cmd_b;
- if (skb_headroom(skb) < TX_OVERHEAD) {
- struct sk_buff *skb2;
-
- skb2 = skb_copy_expand(skb, TX_OVERHEAD, 0, flags);
+ if (skb_cow_head(skb, TX_OVERHEAD)) {
dev_kfree_skb_any(skb);
- skb = skb2;
- if (!skb)
- return NULL;
+ return NULL;
}
if (lan78xx_linearize(skb) < 0)
--
2.12.2.816.g2cccc81164-goog
^ permalink raw reply related
* [PATCH net 3/6] sr9700: use skb_cow_head() to deal with cloned skbs
From: Eric Dumazet @ 2017-04-19 16:59 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, James Hughes, Eric Dumazet, Eric Dumazet
In-Reply-To: <20170419165926.30631-1-edumazet@google.com>
We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.
skb_cow_head() is the proper helper to deal with this.
Fixes: c9b37458e956 ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: James Hughes <james.hughes@raspberrypi.org>
---
drivers/net/usb/sr9700.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
index 4a1e9c489f1f455388ffee289d65e1d6b36cba42..aadfe1d1c37ee67e2a7d17c759db12dad248c41d 100644
--- a/drivers/net/usb/sr9700.c
+++ b/drivers/net/usb/sr9700.c
@@ -456,14 +456,9 @@ static struct sk_buff *sr9700_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
len = skb->len;
- if (skb_headroom(skb) < SR_TX_OVERHEAD) {
- struct sk_buff *skb2;
-
- skb2 = skb_copy_expand(skb, SR_TX_OVERHEAD, 0, flags);
+ if (skb_cow_head(skb, SR_TX_OVERHEAD)) {
dev_kfree_skb_any(skb);
- skb = skb2;
- if (!skb)
- return NULL;
+ return NULL;
}
__skb_push(skb, SR_TX_OVERHEAD);
--
2.12.2.816.g2cccc81164-goog
^ permalink raw reply related
* [PATCH net 1/6] smsc75xx: use skb_cow_head() to deal with cloned skbs
From: Eric Dumazet @ 2017-04-19 16:59 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, James Hughes, Eric Dumazet, Eric Dumazet
In-Reply-To: <20170419165926.30631-1-edumazet@google.com>
We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.
skb_cow_head() is the proper helper to deal with this.
Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: James Hughes <james.hughes@raspberrypi.org>
---
drivers/net/usb/smsc75xx.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 0b17b40d7a4fa2653caf21406c4a6b3b45d868b0..190de9a90f7387c5070c7f589aa18bb7d05ac5d7 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -2203,13 +2203,9 @@ static struct sk_buff *smsc75xx_tx_fixup(struct usbnet *dev,
{
u32 tx_cmd_a, tx_cmd_b;
- if (skb_headroom(skb) < SMSC75XX_TX_OVERHEAD) {
- struct sk_buff *skb2 =
- skb_copy_expand(skb, SMSC75XX_TX_OVERHEAD, 0, flags);
+ if (skb_cow_head(skb, SMSC75XX_TX_OVERHEAD)) {
dev_kfree_skb_any(skb);
- skb = skb2;
- if (!skb)
- return NULL;
+ return NULL;
}
tx_cmd_a = (u32)(skb->len & TX_CMD_A_LEN) | TX_CMD_A_FCS;
--
2.12.2.816.g2cccc81164-goog
^ permalink raw reply related
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