* [PATCH net-next 1/3] net: sched: extend flow_action_entry with destructor
From: Vlad Buslov @ 2019-09-13 15:28 UTC (permalink / raw)
To: netdev; +Cc: jhs, xiyou.wangcong, jiri, davem, Vlad Buslov, Jiri Pirko
In-Reply-To: <20190913152841.15755-1-vladbu@mellanox.com>
Generalize flow_action_entry cleanup by extending the structure with
pointer to destructor function. Set the destructor in
tc_setup_flow_action(). Refactor tc_cleanup_flow_action() to call
entry->destructor() instead of using switch that dispatches by entry->id
and manually executes cleanup.
This refactoring is necessary for following patches in this series that
require destructor to use tc_action->ops callbacks that can't be easily
obtained in tc_cleanup_flow_action().
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
---
include/net/flow_offload.h | 6 ++-
net/sched/cls_api.c | 77 ++++++++++++++++++++++----------------
2 files changed, 50 insertions(+), 33 deletions(-)
diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
index fc881875f856..86c567f531f3 100644
--- a/include/net/flow_offload.h
+++ b/include/net/flow_offload.h
@@ -154,8 +154,12 @@ enum flow_action_mangle_base {
FLOW_ACT_MANGLE_HDR_TYPE_UDP,
};
+typedef void (*action_destr)(void *priv);
+
struct flow_action_entry {
enum flow_action_id id;
+ action_destr destructor;
+ void *destructor_priv;
union {
u32 chain_index; /* FLOW_ACTION_GOTO */
struct net_device *dev; /* FLOW_ACTION_REDIRECT */
@@ -170,7 +174,7 @@ struct flow_action_entry {
u32 mask;
u32 val;
} mangle;
- const struct ip_tunnel_info *tunnel; /* FLOW_ACTION_TUNNEL_ENCAP */
+ struct ip_tunnel_info *tunnel; /* FLOW_ACTION_TUNNEL_ENCAP */
u32 csum_flags; /* FLOW_ACTION_CSUM */
u32 mark; /* FLOW_ACTION_MARK */
u16 ptype; /* FLOW_ACTION_PTYPE */
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 05c4fe1c3ca2..c668195379bd 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -3282,25 +3282,48 @@ void tc_cleanup_flow_action(struct flow_action *flow_action)
struct flow_action_entry *entry;
int i;
- flow_action_for_each(i, entry, flow_action) {
- switch (entry->id) {
- case FLOW_ACTION_REDIRECT:
- case FLOW_ACTION_MIRRED:
- case FLOW_ACTION_REDIRECT_INGRESS:
- case FLOW_ACTION_MIRRED_INGRESS:
- if (entry->dev)
- dev_put(entry->dev);
- break;
- case FLOW_ACTION_TUNNEL_ENCAP:
- kfree(entry->tunnel);
- break;
- default:
- break;
- }
- }
+ flow_action_for_each(i, entry, flow_action)
+ if (entry->destructor)
+ entry->destructor(entry->destructor_priv);
}
EXPORT_SYMBOL(tc_cleanup_flow_action);
+static void tcf_mirred_put_dev(void *priv)
+{
+ struct net_device *dev = priv;
+
+ dev_put(dev);
+}
+
+static void tcf_mirred_get_dev(struct flow_action_entry *entry,
+ const struct tc_action *act)
+{
+ entry->dev = tcf_mirred_dev(act);
+ if (!entry->dev)
+ return;
+ dev_hold(entry->dev);
+ entry->destructor = tcf_mirred_put_dev;
+ entry->destructor_priv = entry->dev;
+}
+
+static void tcf_tunnel_encap_put_tunnel(void *priv)
+{
+ struct ip_tunnel_info *tunnel = priv;
+
+ kfree(tunnel);
+}
+
+static int tcf_tunnel_encap_get_tunnel(struct flow_action_entry *entry,
+ const struct tc_action *act)
+{
+ entry->tunnel = tcf_tunnel_info_copy(act);
+ if (!entry->tunnel)
+ return -ENOMEM;
+ entry->destructor = tcf_tunnel_encap_put_tunnel;
+ entry->destructor_priv = entry->tunnel;
+ return 0;
+}
+
int tc_setup_flow_action(struct flow_action *flow_action,
const struct tcf_exts *exts, bool rtnl_held)
{
@@ -3329,24 +3352,16 @@ int tc_setup_flow_action(struct flow_action *flow_action,
entry->chain_index = tcf_gact_goto_chain_index(act);
} else if (is_tcf_mirred_egress_redirect(act)) {
entry->id = FLOW_ACTION_REDIRECT;
- entry->dev = tcf_mirred_dev(act);
- if (entry->dev)
- dev_hold(entry->dev);
+ tcf_mirred_get_dev(entry, act);
} else if (is_tcf_mirred_egress_mirror(act)) {
entry->id = FLOW_ACTION_MIRRED;
- entry->dev = tcf_mirred_dev(act);
- if (entry->dev)
- dev_hold(entry->dev);
+ tcf_mirred_get_dev(entry, act);
} else if (is_tcf_mirred_ingress_redirect(act)) {
entry->id = FLOW_ACTION_REDIRECT_INGRESS;
- entry->dev = tcf_mirred_dev(act);
- if (entry->dev)
- dev_hold(entry->dev);
+ tcf_mirred_get_dev(entry, act);
} else if (is_tcf_mirred_ingress_mirror(act)) {
entry->id = FLOW_ACTION_MIRRED_INGRESS;
- entry->dev = tcf_mirred_dev(act);
- if (entry->dev)
- dev_hold(entry->dev);
+ tcf_mirred_get_dev(entry, act);
} else if (is_tcf_vlan(act)) {
switch (tcf_vlan_action(act)) {
case TCA_VLAN_ACT_PUSH:
@@ -3370,11 +3385,9 @@ int tc_setup_flow_action(struct flow_action *flow_action,
}
} else if (is_tcf_tunnel_set(act)) {
entry->id = FLOW_ACTION_TUNNEL_ENCAP;
- entry->tunnel = tcf_tunnel_info_copy(act);
- if (!entry->tunnel) {
- err = -ENOMEM;
+ err = tcf_tunnel_encap_get_tunnel(entry, act);
+ if (err)
goto err_out;
- }
} else if (is_tcf_tunnel_release(act)) {
entry->id = FLOW_ACTION_TUNNEL_DECAP;
} else if (is_tcf_pedit(act)) {
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 0/3] More fixes for unlocked cls hardware offload API refactoring
From: Vlad Buslov @ 2019-09-13 15:28 UTC (permalink / raw)
To: netdev; +Cc: jhs, xiyou.wangcong, jiri, davem, Vlad Buslov
Two fixes for my "Refactor cls hardware offload API to support
rtnl-independent drivers" series and refactoring patch that implements
infrastructure necessary for the fixes.
Vlad Buslov (3):
net: sched: extend flow_action_entry with destructor
net: sched: take reference to psample group in flow_action infra
net: sched: use get_dev() action API in flow_action infra
include/net/act_api.h | 9 +++-
include/net/flow_offload.h | 6 ++-
include/net/psample.h | 1 +
include/net/tc_act/tc_sample.h | 6 ---
net/psample/psample.c | 20 +++++---
net/sched/act_mirred.c | 21 +++++----
net/sched/act_sample.c | 27 +++++++++++
net/sched/cls_api.c | 83 ++++++++++++++++++++--------------
8 files changed, 116 insertions(+), 57 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [PATCH net-next] MAINTAINERS: xen-netback: update my email address
From: Wei Liu @ 2019-09-13 15:28 UTC (permalink / raw)
To: Paul Durrant; +Cc: netdev, xen-devel, Wei Liu
In-Reply-To: <20190913124727.3277-1-paul.durrant@citrix.com>
On Fri, 13 Sep 2019 at 13:47, Paul Durrant <paul.durrant@citrix.com> wrote:
>
> My Citrix email address will expire shortly.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Wei Liu <wl@xen.org>
^ permalink raw reply
* Re: [PATCH 1/3] rtlwifi: rtl8192ce: replace _rtl92c_evm_db_to_percentage with generic version
From: Kalle Valo @ 2019-09-13 15:07 UTC (permalink / raw)
To: Michael Straube
Cc: pkshih, davem, linux-wireless, netdev, linux-kernel,
Michael Straube
In-Reply-To: <20190910190422.63378-2-straube.linux@gmail.com>
Michael Straube <straube.linux@gmail.com> wrote:
> Function _rtl92c_evm_db_to_percentage is functionally identical
> to the generic version rtl_evm_db_to_percentage, so remove
> _rtl92c_evm_db_to_percentage and use the generic version instead.
>
> Signed-off-by: Michael Straube <straube.linux@gmail.com>
3 patches applied to wireless-drivers-next.git, thanks.
1335ad27bd07 rtlwifi: rtl8192ce: replace _rtl92c_evm_db_to_percentage with generic version
622c19ed3607 rtlwifi: rtl8192cu: replace _rtl92c_evm_db_to_percentage with generic version
3a1f85798e9f rtlwifi: rtl8192de: replace _rtl92d_evm_db_to_percentage with generic version
--
https://patchwork.kernel.org/patch/11140005/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
From: Jiri Pirko @ 2019-09-13 14:50 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Michal Kubecek, netdev, David Miller, Jakub Kicinski, David Ahern,
Stephen Hemminger, dcbw, Andrew Lunn, parav, Saeed Mahameed,
mlxsw
In-Reply-To: <20190912115942.GC7621@nanopsycho.orion>
Thu, Sep 12, 2019 at 01:59:42PM CEST, jiri@resnulli.us wrote:
>Fri, Aug 30, 2019 at 07:03:42PM CEST, jiri@resnulli.us wrote:
>>Fri, Aug 30, 2019 at 04:35:23PM CEST, roopa@cumulusnetworks.com wrote:
>
>[...]
>
>>>
>>>so to summarize, i think we have discussed the following options to
>>>update a netlink list attribute so far:
>>>(a) encode an optional attribute/flag in the list attribute in
>>>RTM_SETLINK to indicate if it is a add or del
>>>(b) Use a flag in RTM_SETLINK and RTM_DELINK to indicate add/del
>>>(close to bridge vlan add/del)
>>
>>Nope, bridge vlan add/del is done according to the cmd, not any flag.
>>
>>
>>>(c) introduce a separate generic msg type to add/del to a list
>>>attribute (IIUC this does need a separate msg type per subsystem or
>>>netlink API)
>
>Getting back to this, sorry.
>
>Thinking about it for some time, a,b,c have all their issues. Why can't
>we have another separate cmd as I originally proposed in this RFC? Does
>anyone have any argument against it? Could you please describe?
>
>Because otherwise, I don't feel comfortable going to any of a,b,c :(
How about this:
We have new commands, but we have them for lists of many types. In my
examples, I'm using "altname" and "color". This is very similar to
bridge vlan example Roopa pointed out. It scales and does not pollute
existing setlink/getlink messages. Also, the cmdline is aligned:
$ ip link property add eth0 altname someverylongname altname someotherlongname
$ ip link property add eth0 altname someotherveryverylongname color blue
$ ip link property del eth0 altname someverylongname color blue
$ ip link property add eth0 color red
$ ip link property show eth0
2: eth0: altname someotherlongname altname someotherveryverylongname color red
$ ip -j -p link property show eth0
[ {
"ifindex": 2,
"ifname": "eth0",
"property": [ "altname": "someotherlongname",
"altname": "someotherveryverylongname",
"color": "red"]
} ]
I call this "property" but I'm open to any other naming.
^ permalink raw reply
* Re: [PATCH net] udp: correct reuseport selection with connected sockets
From: Paolo Abeni @ 2019-09-13 14:47 UTC (permalink / raw)
To: Willem de Bruijn, netdev
Cc: davem, edumazet, kraig, zabele, mark.keaton, Willem de Bruijn
In-Reply-To: <20190913011639.55895-1-willemdebruijn.kernel@gmail.com>
On Thu, 2019-09-12 at 21:16 -0400, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> UDP reuseport groups can hold a mix unconnected and connected sockets.
> Ensure that connections only receive all traffic to their 4-tuple.
>
> Fast reuseport returns on the first reuseport match on the assumption
> that all matches are equal. Only if connections are present, return to
> the previous behavior of scoring all sockets.
>
> Record if connections are present and if so (1) treat such connected
> sockets as an independent match from the group, (2) only return
> 2-tuple matches from reuseport and (3) do not return on the first
> 2-tuple reuseport match to allow for a higher scoring match later.
>
> New field has_conns is set without locks. No other fields in the
> bitmap are modified at runtime and the field is only ever set
> unconditionally, so an RMW cannot miss a change.
>
> Fixes: e32ea7e74727 ("soreuseport: fast reuseport UDP socket selection")
> Link: http://lkml.kernel.org/r/CA+FuTSfRP09aJNYRt04SS6qj22ViiOEWaWmLAwX0psk8-PGNxw@mail.gmail.com
> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> ---
>
> I was unable to compile some older kernels, so the Fixes tag is based
> on basic analysis, not bisected to by the regression test.
> ---
> include/net/sock_reuseport.h | 20 +++++++++++++++++++-
> net/core/sock_reuseport.c | 15 +++++++++++++--
> net/ipv4/datagram.c | 2 ++
> net/ipv4/udp.c | 5 +++--
> net/ipv6/datagram.c | 2 ++
> net/ipv6/udp.c | 5 +++--
> 6 files changed, 42 insertions(+), 7 deletions(-)
>
> diff --git a/include/net/sock_reuseport.h b/include/net/sock_reuseport.h
> index d9112de85261..43f4a818d88f 100644
> --- a/include/net/sock_reuseport.h
> +++ b/include/net/sock_reuseport.h
> @@ -21,7 +21,8 @@ struct sock_reuseport {
> unsigned int synq_overflow_ts;
> /* ID stays the same even after the size of socks[] grows. */
> unsigned int reuseport_id;
> - bool bind_inany;
> + unsigned int bind_inany:1;
> + unsigned int has_conns:1;
> struct bpf_prog __rcu *prog; /* optional BPF sock selector */
> struct sock *socks[0]; /* array of sock pointers */
> };
> @@ -37,6 +38,23 @@ extern struct sock *reuseport_select_sock(struct sock *sk,
> extern int reuseport_attach_prog(struct sock *sk, struct bpf_prog *prog);
> extern int reuseport_detach_prog(struct sock *sk);
>
> +static inline bool reuseport_has_conns(struct sock *sk, bool set)
> +{
> + struct sock_reuseport *reuse;
> + bool ret = false;
> +
> + rcu_read_lock();
> + reuse = rcu_dereference(sk->sk_reuseport_cb);
> + if (reuse) {
> + if (set)
> + reuse->has_conns = 1;
> + ret = reuse->has_conns;
> + }
> + rcu_read_unlock();
> +
> + return ret;
> +}
> +
> int reuseport_get_id(struct sock_reuseport *reuse);
>
> #endif /* _SOCK_REUSEPORT_H */
> diff --git a/net/core/sock_reuseport.c b/net/core/sock_reuseport.c
> index 9408f9264d05..f3ceec93f392 100644
> --- a/net/core/sock_reuseport.c
> +++ b/net/core/sock_reuseport.c
> @@ -295,8 +295,19 @@ struct sock *reuseport_select_sock(struct sock *sk,
>
> select_by_hash:
> /* no bpf or invalid bpf result: fall back to hash usage */
> - if (!sk2)
> - sk2 = reuse->socks[reciprocal_scale(hash, socks)];
> + if (!sk2) {
> + int i, j;
> +
> + i = j = reciprocal_scale(hash, socks);
> + while (reuse->socks[i]->sk_state == TCP_ESTABLISHED) {
> + i++;
> + if (i >= reuse->num_socks)
> + i = 0;
> + if (i == j)
> + goto out;
> + }
> + sk2 = reuse->socks[i];
> + }
> }
>
> out:
> diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
> index 7bd29e694603..9a0fe0c2fa02 100644
> --- a/net/ipv4/datagram.c
> +++ b/net/ipv4/datagram.c
> @@ -15,6 +15,7 @@
> #include <net/sock.h>
> #include <net/route.h>
> #include <net/tcp_states.h>
> +#include <net/sock_reuseport.h>
>
> int __ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
> {
> @@ -69,6 +70,7 @@ int __ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len
> }
> inet->inet_daddr = fl4->daddr;
> inet->inet_dport = usin->sin_port;
> + reuseport_has_conns(sk, true);
> sk->sk_state = TCP_ESTABLISHED;
> sk_set_txhash(sk);
> inet->inet_id = jiffies;
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index d88821c794fb..16486c8b708b 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -423,12 +423,13 @@ static struct sock *udp4_lib_lookup2(struct net *net,
> score = compute_score(sk, net, saddr, sport,
> daddr, hnum, dif, sdif);
> if (score > badness) {
> - if (sk->sk_reuseport) {
> + if (sk->sk_reuseport &&
> + sk->sk_state != TCP_ESTABLISHED) {
> hash = udp_ehashfn(net, daddr, hnum,
> saddr, sport);
> result = reuseport_select_sock(sk, hash, skb,
> sizeof(struct udphdr));
> - if (result)
> + if (result && !reuseport_has_conns(sk, false))
> return result;
> }
> badness = score;
> diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
> index 9ab897ded4df..96f939248d2f 100644
> --- a/net/ipv6/datagram.c
> +++ b/net/ipv6/datagram.c
> @@ -27,6 +27,7 @@
> #include <net/ip6_route.h>
> #include <net/tcp_states.h>
> #include <net/dsfield.h>
> +#include <net/sock_reuseport.h>
>
> #include <linux/errqueue.h>
> #include <linux/uaccess.h>
> @@ -254,6 +255,7 @@ int __ip6_datagram_connect(struct sock *sk, struct sockaddr *uaddr,
> goto out;
> }
>
> + reuseport_has_conns(sk, true);
> sk->sk_state = TCP_ESTABLISHED;
> sk_set_txhash(sk);
> out:
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 827fe7385078..5995fdc99d3f 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -158,13 +158,14 @@ static struct sock *udp6_lib_lookup2(struct net *net,
> score = compute_score(sk, net, saddr, sport,
> daddr, hnum, dif, sdif);
> if (score > badness) {
> - if (sk->sk_reuseport) {
> + if (sk->sk_reuseport &&
> + sk->sk_state != TCP_ESTABLISHED) {
> hash = udp6_ehashfn(net, daddr, hnum,
> saddr, sport);
>
> result = reuseport_select_sock(sk, hash, skb,
> sizeof(struct udphdr));
> - if (result)
> + if (result && !reuseport_has_conns(sk, false))
> return result;
> }
> result = sk;
The patch LGTM,
Acked-by: Paolo Abeni <pabeni@redhat.com>
^ permalink raw reply
* net: phy: micrel KSZ9031 ifdown ifup issue
From: Paul Thomas @ 2019-09-13 14:42 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S. Miller,
netdev
Hello,
I think I'm seeing an issue with the PHY hardware or PHY driver. What
happens is sometimes (but not always) when I do 'ip link set eth0
down' followed by 'ip link set eth0 up' I don't ever see an
auto-negotiation again. LEDs don't come on, ethtool reports 'Link
detected: no'. Even physically unplugging and plugging the network
cable doesn't bring it back. I have to do a reboot to get the
networking back.
When the networking is started I don't see any issue forcing
negotiations by unplugging and plugging the cable. I get standard
messages like this all day long:
[ 21.031793] 003: macb ff0b0000.ethernet eth0: link down
[ 26.142835] 003: macb ff0b0000.ethernet eth0: link up (1000/Full)
One thing that makes me think this is the PHY is that we have another
Ethernet port using the DP83867 PHY and I can always do ifdown/ifup
with it.
This is using a 5.2.10 kernel on arm64 zynqmp platform with the macb driver.
Is this something anyone else has seen? I know there is some Errata
with this part, but I'm hoping there is something to fix or work
around this. Any thoughts on where to look or add debugging would
appreciated.
thanks,
Paul
^ permalink raw reply
* Re: [PATCH v3 2/2] tcp: Add rcv_wnd to TCP_INFO
From: Neal Cardwell @ 2019-09-13 14:37 UTC (permalink / raw)
To: Thomas Higdon
Cc: Dave Taht, netdev@vger.kernel.org, Jonathan Lemon, Dave Jones,
Eric Dumazet, Yuchung Cheng, Soheil Hassas Yeganeh
In-Reply-To: <20190913142936.GA84687@tph-mbp>
On Fri, Sep 13, 2019 at 10:29 AM Thomas Higdon <tph@fb.com> wrote:
>
> On Thu, Sep 12, 2019 at 10:14:33AM +0100, Dave Taht wrote:
> > On Thu, Sep 12, 2019 at 1:59 AM Neal Cardwell <ncardwell@google.com> wrote:
> > >
> > > On Wed, Sep 11, 2019 at 6:32 PM Thomas Higdon <tph@fb.com> wrote:
> > > >
> > > > Neal Cardwell mentioned that rcv_wnd would be useful for helping
> > > > diagnose whether a flow is receive-window-limited at a given instant.
> > > >
> > > > This serves the purpose of adding an additional __u32 to avoid the
> > > > would-be hole caused by the addition of the tcpi_rcvi_ooopack field.
> > > >
> > > > Signed-off-by: Thomas Higdon <tph@fb.com>
> > > > ---
> > >
> > > Thanks, Thomas.
> > >
> > > I know that when I mentioned this before I mentioned the idea of both
> > > tp->snd_wnd (send-side receive window) and tp->rcv_wnd (receive-side
> > > receive window) in tcp_info, and did not express a preference between
> > > the two. Now that we are faced with a decision between the two,
> > > personally I think it would be a little more useful to start with
> > > tp->snd_wnd. :-)
> > >
> > > Two main reasons:
> > >
> > > (1) Usually when we're diagnosing TCP performance problems, we do so
> > > from the sender, since the sender makes most of the
> > > performance-critical decisions (cwnd, pacing, TSO size, TSQ, etc).
> > > From the sender-side the thing that would be most useful is to see
> > > tp->snd_wnd, the receive window that the receiver has advertised to
> > > the sender.
> >
> > I am under the impression, that particularly in the mobile space, that
> > network behavior
> > is often governed by rcv_wnd. At least, there's been so many papers on
> > this that I'd
> > tended to assume so.
> >
> > Given a desire to do both vars, is there a *third* u32 we could add to
> > fill in the next hole? :)
> > ecn marks?
>
> Neal makes some good points -- there is a fair amount of existing
> information for deriving receive window. It seems like snd_wnd would be
> more valuable at this moment. For the purpose of pairing up these __u32s
> to get something we can commit, I propose that we go with
> the rcv_ooopack/snd_wnd pair for now, and when something comes up later,
> one might consider pairing up rcv_wnd.
FWIW that sounds like a great plan to me. Thanks, Thomas!
neal
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: net: dwmac: document 'mac-mode' property
From: Rob Herring @ 2019-09-13 14:36 UTC (permalink / raw)
To: Alexandru Ardelean
Cc: netdev, devicetree, linux-kernel, davem, peppe.cavallaro,
alexandre.torgue, --cc=andrew
In-Reply-To: <20190906130256.10321-2-alexandru.ardelean@analog.com>
On Fri, Sep 06, 2019 at 04:02:56PM +0300, Alexandru Ardelean wrote:
> This change documents the 'mac-mode' property that was introduced in the
> 'stmmac' driver to support passive mode converters that can sit in-between
> the MAC & PHY.
>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
> Documentation/devicetree/bindings/net/snps,dwmac.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> index c78be15704b9..ebe4537a7cce 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> @@ -112,6 +112,14 @@ properties:
> reset-names:
> const: stmmaceth
>
> + mac-mode:
> + maxItems: 1
Is this an array because {min,max}Items is for arrays? It should be
defined as a string with possible values.
As this property is the same as another, you can do this:
$ref: ethernet-controller.yaml#/properties/phy-connection-type
Unless only a small subset of those values are valid here, then you may
want to list them here.
> + description:
> + The property is identical to 'phy-mode', and assumes that there is mode
> + converter in-between the MAC & PHY (e.g. GMII-to-RGMII). This converter
> + can be passive (no SW requirement), and requires that the MAC operate
> + in a different mode than the PHY in order to function.
> +
> snps,axi-config:
> $ref: /schemas/types.yaml#definitions/phandle
> description:
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH v3 2/2] tcp: Add rcv_wnd to TCP_INFO
From: Thomas Higdon @ 2019-09-13 14:29 UTC (permalink / raw)
To: Dave Taht
Cc: Neal Cardwell, netdev@vger.kernel.org, Jonathan Lemon, Dave Jones,
Eric Dumazet, Yuchung Cheng, Soheil Hassas Yeganeh
In-Reply-To: <CAA93jw7q71mpenRMD0dWiVNap1WKD6O4+GCBagcPa5OhHTMErw@mail.gmail.com>
On Thu, Sep 12, 2019 at 10:14:33AM +0100, Dave Taht wrote:
> On Thu, Sep 12, 2019 at 1:59 AM Neal Cardwell <ncardwell@google.com> wrote:
> >
> > On Wed, Sep 11, 2019 at 6:32 PM Thomas Higdon <tph@fb.com> wrote:
> > >
> > > Neal Cardwell mentioned that rcv_wnd would be useful for helping
> > > diagnose whether a flow is receive-window-limited at a given instant.
> > >
> > > This serves the purpose of adding an additional __u32 to avoid the
> > > would-be hole caused by the addition of the tcpi_rcvi_ooopack field.
> > >
> > > Signed-off-by: Thomas Higdon <tph@fb.com>
> > > ---
> >
> > Thanks, Thomas.
> >
> > I know that when I mentioned this before I mentioned the idea of both
> > tp->snd_wnd (send-side receive window) and tp->rcv_wnd (receive-side
> > receive window) in tcp_info, and did not express a preference between
> > the two. Now that we are faced with a decision between the two,
> > personally I think it would be a little more useful to start with
> > tp->snd_wnd. :-)
> >
> > Two main reasons:
> >
> > (1) Usually when we're diagnosing TCP performance problems, we do so
> > from the sender, since the sender makes most of the
> > performance-critical decisions (cwnd, pacing, TSO size, TSQ, etc).
> > From the sender-side the thing that would be most useful is to see
> > tp->snd_wnd, the receive window that the receiver has advertised to
> > the sender.
>
> I am under the impression, that particularly in the mobile space, that
> network behavior
> is often governed by rcv_wnd. At least, there's been so many papers on
> this that I'd
> tended to assume so.
>
> Given a desire to do both vars, is there a *third* u32 we could add to
> fill in the next hole? :)
> ecn marks?
Neal makes some good points -- there is a fair amount of existing
information for deriving receive window. It seems like snd_wnd would be
more valuable at this moment. For the purpose of pairing up these __u32s
to get something we can commit, I propose that we go with
the rcv_ooopack/snd_wnd pair for now, and when something comes up later,
one might consider pairing up rcv_wnd.
^ permalink raw reply
* Re: [PATCH] libertas: use mesh_wdev->ssid instead of priv->mesh_ssid
From: Kalle Valo @ 2019-09-13 14:24 UTC (permalink / raw)
To: Lubomir Rintel
Cc: libertas-dev, linux-wireless, netdev, linux-kernel,
Lubomir Rintel
In-Reply-To: <20190907151855.2637984-1-lkundrak@v3.sk>
Lubomir Rintel <lkundrak@v3.sk> wrote:
> With the commit e86dc1ca4676 ("Libertas: cfg80211 support") we've lost
> the ability to actually set the Mesh SSID from userspace.
> NL80211_CMD_SET_INTERFACE with NL80211_ATTR_MESH_ID sets the mesh point
> interface's ssid field. Let's use that one for the Libertas Mesh
> operation
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Patch applied to wireless-drivers-next.git, thanks.
2199c9817670 libertas: use mesh_wdev->ssid instead of priv->mesh_ssid
--
https://patchwork.kernel.org/patch/11136509/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmsmac: Use DIV_ROUND_CLOSEST directly to make it readable
From: Kalle Valo @ 2019-09-13 14:20 UTC (permalink / raw)
To: zhong jiang; +Cc: davem, zhongjiang, linux-wireless, netdev, linux-kernel
In-Reply-To: <1567700648-28162-1-git-send-email-zhongjiang@huawei.com>
zhong jiang <zhongjiang@huawei.com> wrote:
> The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d
> but is perhaps more readable.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
3dfb22003f98 brcmsmac: Use DIV_ROUND_CLOSEST directly to make it readable
--
https://patchwork.kernel.org/patch/11133663/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v4 2/2] PTP: add support for one-shot output
From: David Miller @ 2019-09-13 13:57 UTC (permalink / raw)
To: felipe.balbi; +Cc: richardcochran, christopher.s.hall, netdev, linux-kernel
In-Reply-To: <20190911061622.774006-2-felipe.balbi@linux.intel.com>
From: Felipe Balbi <felipe.balbi@linux.intel.com>
Date: Wed, 11 Sep 2019 09:16:22 +0300
> Some controllers allow for a one-shot output pulse, in contrast to
> periodic output. Now that we have extensible versions of our IOCTLs, we
> can finally make use of the 'flags' field to pass a bit telling driver
> that if we want one-shot pulse output.
>
> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH v4 1/2] PTP: introduce new versions of IOCTLs
From: David Miller @ 2019-09-13 13:57 UTC (permalink / raw)
To: felipe.balbi; +Cc: richardcochran, christopher.s.hall, netdev, linux-kernel
In-Reply-To: <20190911061622.774006-1-felipe.balbi@linux.intel.com>
From: Felipe Balbi <felipe.balbi@linux.intel.com>
Date: Wed, 11 Sep 2019 09:16:21 +0300
> The current version of the IOCTL have a small problem which prevents us
> from extending the API by making use of reserved fields. In these new
> IOCTLs, we are now making sure that flags and rsv fields are zero which
> will allow us to extend the API in the future.
>
> Reviewed-by: Richard Cochran <richardcochran@gmail.com>
> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Applied.
^ permalink raw reply
* Re: [net] ixgbevf: Fix secpath usage for IPsec Tx offload
From: David Miller @ 2019-09-13 13:53 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, snelson, jonathan
In-Reply-To: <20190912190734.10560-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 12 Sep 2019 12:07:34 -0700
> Port the same fix for ixgbe to ixgbevf.
>
> The ixgbevf driver currently does IPsec Tx offloading
> based on an existing secpath. However, the secpath
> can also come from the Rx side, in this case it is
> misinterpreted for Tx offload and the packets are
> dropped with a "bad sa_idx" error. Fix this by using
> the xfrm_offload() function to test for Tx offload.
>
> CC: Shannon Nelson <snelson@pensando.io>
> Fixes: 7f68d4306701 ("ixgbevf: enable VF IPsec offload operations")
> Reported-by: Jonathan Tooker <jonathan@reliablehosting.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, and like the ixgbe version of this fix I queued it up for -stable.
Thanks.
^ permalink raw reply
* Re: [net-next 0/6][pull request] 100GbE Intel Wired LAN Driver Updates 2019-09-12
From: David Miller @ 2019-09-13 13:51 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190912205002.12159-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 12 Sep 2019 13:49:56 -0700
> This series contains updates to ice driver to implement and support
> loading a Dynamic Device Personalization (DDP) package from lib/firmware
> onto the device.
>
> Paul updates the way the driver version is stored in the driver so that
> we can pass the driver version to the firmware. Passing of the driver
> version to the firmware is needed for the DDP package to ensure we have
> the appropriate support in the driver for the features in the package.
>
> Lukasz fixes how the firmware version is stored to align with how the
> firmware stores its own version. Also extended the log message to
> display additional useful information such as NVM version, API patch
> information and firmware build hash.
>
> Tony adds the needed driver support to check, load and store the DDP
> package. Also add support for the ability to load DDP packages intended
> for specific hardware devices, as well as what to do when loading of the
> DDP package fails to load.
>
> The following are changes since commit 172ca8308b0517ca2522a8c885755fd5c20294e7:
> cxgb4: Fix spelling typos
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 100GbE
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [net-next v2 00/13][pull request] Intel Wired LAN Driver Updates 2019-09-11
From: David Miller @ 2019-09-13 13:48 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190911165014.10742-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 11 Sep 2019 09:50:01 -0700
> This series contains updates to i40e, ixgbe/vf and iavf.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8821ae: make array static const and remove redundant assignment
From: Kalle Valo @ 2019-09-13 13:44 UTC (permalink / raw)
To: Colin King
Cc: Ping-Ke Shih, David S . Miller, Larry Finger, linux-wireless,
netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190905150022.3609-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The array channel_all can be make static const rather than populating
> it on the stack, this makes the code smaller. Also, variable place
> is being initialized with a value that is never read, so this assignment
> is redundant and can be removed.
>
> Before:
> text data bss dec hex filename
> 118537 9591 0 128128 1f480 realtek/rtlwifi/rtl8821ae/phy.o
>
> After:
> text data bss dec hex filename
> 118331 9687 0 128018 1f412 realtek/rtlwifi/rtl8821ae/phy.o
>
> Saves 110 bytes, (gcc version 9.2.1, amd64)
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
569ce0a486fd rtlwifi: rtl8821ae: make array static const and remove redundant assignment
--
https://patchwork.kernel.org/patch/11133295/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH 1/1] MAINTAINERS: update FORCEDETH MAINTAINERS info
From: rain.1986.08.12 @ 2019-09-13 13:43 UTC (permalink / raw)
To: mchehab+samsung, davem, gregkh, linux-kernel, rain.1986.08.12,
netdev
From: Rain River <rain.1986.08.12@gmail.com>
Many FORCEDETH NICs are used in our hosts. Several bugs are fixed and
some features are developed for FORCEDETH NICs. And I have been
reviewing patches for FORCEDETH NIC for several months. Mark me as the
FORCEDETH NIC maintainer. I will send out the patches and maintain
FORCEDETH NIC.
Signed-off-by: Rain River <rain.1986.08.12@gmail.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e7a47b5210fd..0a28090df677 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -649,6 +649,12 @@ M: Lino Sanfilippo <LinoSanfilippo@gmx.de>
S: Maintained
F: drivers/net/ethernet/alacritech/*
+FORCEDETH GIGABIT ETHERNET DRIVER
+M: Rain River <rain.1986.08.12@gmail.com>
+L: netdev@vger.kernel.org
+S: Maintained
+F: drivers/net/ethernet/nvidia/*
+
ALCATEL SPEEDTOUCH USB DRIVER
M: Duncan Sands <duncan.sands@free.fr>
L: linux-usb@vger.kernel.org
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] netfilter: trivial: remove extraneous space from message
From: Rui Salvaterra @ 2019-09-13 13:43 UTC (permalink / raw)
To: pablo, davem, netfilter-devel, netdev, linux-kernel
In-Reply-To: <20190724143733.17433-1-rsalvaterra@gmail.com>
Friendly ping.
On Wed, 24 Jul 2019 at 15:37, Rui Salvaterra <rsalvaterra@gmail.com> wrote:
>
> Pure ocd, but this one has been bugging me for a while.
>
> Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
> ---
> net/netfilter/nf_conntrack_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/netfilter/nf_conntrack_helper.c b/net/netfilter/nf_conntrack_helper.c
> index 8d729e7c36ff..209123f35b4a 100644
> --- a/net/netfilter/nf_conntrack_helper.c
> +++ b/net/netfilter/nf_conntrack_helper.c
> @@ -218,7 +218,7 @@ nf_ct_lookup_helper(struct nf_conn *ct, struct net *net)
> return NULL;
> pr_info("nf_conntrack: default automatic helper assignment "
> "has been turned off for security reasons and CT-based "
> - " firewall rule not found. Use the iptables CT target "
> + "firewall rule not found. Use the iptables CT target "
> "to attach helpers instead.\n");
> net->ct.auto_assign_helper_warned = 1;
> return NULL;
> --
> 2.22.0
>
^ permalink raw reply
* Re: [PATCH 00/27] Netfilter updates for net-next
From: David Miller @ 2019-09-13 13:40 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20190913113102.15776-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri, 13 Sep 2019 13:30:35 +0200
> The following patchset contains Netfilter updates for net-next:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Looks good, pulled.
^ permalink raw reply
* Re: [PATCH net-next 5/5] sctp: add spt_pathcpthld in struct sctp_paddrthlds
From: 'Marcelo Ricardo Leitner' @ 2019-09-13 13:40 UTC (permalink / raw)
To: David Laight
Cc: Xin Long, network dev, linux-sctp@vger.kernel.org, Neil Horman,
davem@davemloft.net
In-Reply-To: <be14cc8353f6403c82ad81e3e741d8f0@AcuMS.aculab.com>
On Fri, Sep 13, 2019 at 01:31:22PM +0000, David Laight wrote:
> From: 'Marcelo Ricardo Leitner'
> > Sent: 13 September 2019 14:20
> ...
> > Interestingly, we have/had the opposite problem with netlink. Like, it
> > was allowing too much flexibility, such as silently ignoring unknown
> > fields (which is what would happen with a new app running on an older
> > kernel would trigger here) is bad because the app cannot know if it
> > was actually used or not. Some gymnastics in the app could cut through
> > the fat here, like probing getsockopt() return size, but then it may
> > as well probe for the right sockopt to be used.
>
> Yes, it would also work if the kernel checked that all 'unexpected'
> fields were zero (up to some sanity limit of a few kB).
Though this would have to be done by older kernels, which are not
aware of this extra space by definition.
>
> Then an application complied with a 'new' header would work with
> an old kernel provided it didn't try so set any new fields.
> (And it zeroed the entire structure.)
>
> But you have to start off with that in mind.
>
> Alternatively stop the insanity of setting multiple options
> with one setsockopt call.
> If multiple system calls are an issue implement a system call
> that will set multiple options on the same socket.
> (Maybe through a CMSG()-like buffer).
> Then the application can set the ones it wants without having
> to do the read-modify-write sequence needed for some of the
> SCTP ones.
I'm not sure I get you here. You mean we could have, for example, one
sockopt for each field on each struct we currently have? That would
bring other problems to the table, like how to deal with fields that
need to be updated together.
Anyhow, I'm afraid our hands a bit tied here. That's how the RFCs are
defining the interface and we shouldn't deviate too much from it.
What would help is that the RFC definited these versioned structs
itself. Because as it is, even if we start versioning it, Linux will
have one versioning and other OSes will have another.
Marcelo
^ permalink raw reply
* Re: [PATCH 3/3] libertas: Remove unneeded variable and make function to be void
From: Kalle Valo @ 2019-09-13 13:38 UTC (permalink / raw)
To: zhong jiang; +Cc: davem, zhongjiang, linux-wireless, netdev, linux-kernel
In-Reply-To: <1568306492-42998-4-git-send-email-zhongjiang@huawei.com>
zhong jiang <zhongjiang@huawei.com> wrote:
> lbs_process_event do not need return value to cope with different
> cases. And change functon return type to void.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Same here, I just don't see the benefit.
Patch set to Rejected.
--
https://patchwork.kernel.org/patch/11143397/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/3] brcmsmac: Remove unneeded variable and make function to be void
From: Kalle Valo @ 2019-09-13 13:37 UTC (permalink / raw)
To: zhong jiang; +Cc: davem, zhongjiang, linux-wireless, netdev, linux-kernel
In-Reply-To: <1568306492-42998-2-git-send-email-zhongjiang@huawei.com>
zhong jiang <zhongjiang@huawei.com> wrote:
> brcms_c_set_mac do not need return value to cope with different
> cases. And change functon return type to void.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
I just don't see the benefit from changing the function to return void.
And if we ever add error handling to the function we need to change it
back to return int again, which is extra work.
Patch set to Rejected.
--
https://patchwork.kernel.org/patch/11143403/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* RE: [PATCH net-next 5/5] sctp: add spt_pathcpthld in struct sctp_paddrthlds
From: David Laight @ 2019-09-13 13:31 UTC (permalink / raw)
To: 'Marcelo Ricardo Leitner'
Cc: Xin Long, network dev, linux-sctp@vger.kernel.org, Neil Horman,
davem@davemloft.net
In-Reply-To: <20190913131954.GX3431@localhost.localdomain>
From: 'Marcelo Ricardo Leitner'
> Sent: 13 September 2019 14:20
...
> Interestingly, we have/had the opposite problem with netlink. Like, it
> was allowing too much flexibility, such as silently ignoring unknown
> fields (which is what would happen with a new app running on an older
> kernel would trigger here) is bad because the app cannot know if it
> was actually used or not. Some gymnastics in the app could cut through
> the fat here, like probing getsockopt() return size, but then it may
> as well probe for the right sockopt to be used.
Yes, it would also work if the kernel checked that all 'unexpected'
fields were zero (up to some sanity limit of a few kB).
Then an application complied with a 'new' header would work with
an old kernel provided it didn't try so set any new fields.
(And it zeroed the entire structure.)
But you have to start off with that in mind.
Alternatively stop the insanity of setting multiple options
with one setsockopt call.
If multiple system calls are an issue implement a system call
that will set multiple options on the same socket.
(Maybe through a CMSG()-like buffer).
Then the application can set the ones it wants without having
to do the read-modify-write sequence needed for some of the
SCTP ones.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox