* Re: [RFC] switchdev: generate phys_port_name in the core
From: Jiri Pirko @ 2017-07-28 5:35 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Or Gerlitz, netdev, Or Gerlitz, Michael Chan, Sathya Perla,
David Miller, simon.horman
In-Reply-To: <20170728023122.1674-1-jakub.kicinski@netronome.com>
Fri, Jul 28, 2017 at 04:31:22AM CEST, jakub.kicinski@netronome.com wrote:
>On Thu, 27 Jul 2017 13:30:44 +0300, Or Gerlitz wrote:
>> > want to add port splitting support, for example, reporting the name on
>> > physical ports will become more of a necessity.
>>
>> > If we adopt Jiri's suggestion of returning structured data it will be
>> > very easy to give user space type and indexes separately, but we should
>> > probably still return the string for backwards compatibility.
>>
>> I am not still clear how the structured data would look like
>
>I decided to just quickly write the code, that should be easier to
>understand. We can probably leave out the netlink part of the API
>if there is no need for it right now, but that's what I ment by
>returning the information in a more structured way.
>
>Tested-by: nobody :)
>Suggested-by: Jiri (if I understood correctly)
Yes, you did :) Couple of nits inlined.
>---
> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 8 ++-
> drivers/net/ethernet/mellanox/mlxsw/switchx2.c | 10 ++--
> drivers/net/ethernet/netronome/nfp/nfp_port.c | 26 ++++-----
> drivers/net/ethernet/netronome/nfp/nfp_port.h | 4 +-
> include/linux/netdevice.h | 18 ++++++-
> include/uapi/linux/if_link.h | 16 ++++++
> net/core/dev.c | 31 +++++++++--
> net/core/rtnetlink.c | 69 ++++++++++++++++++++++++
> 8 files changed, 153 insertions(+), 29 deletions(-)
>
>diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>index 45e60be9c277..7a71291b8ec3 100644
>--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>@@ -637,16 +637,14 @@ static int mlx5e_rep_close(struct net_device *dev)
> }
>
> static int mlx5e_rep_get_phys_port_name(struct net_device *dev,
>- char *buf, size_t len)
>+ struct netdev_port_info *info)
Either we rename ndo to something like ndo_get_port_info or you rename
the struct to netdev_port_name_info. These 2 should be in sync
> {
> struct mlx5e_priv *priv = netdev_priv(dev);
> struct mlx5e_rep_priv *rpriv = priv->ppriv;
> struct mlx5_eswitch_rep *rep = rpriv->rep;
>- int ret;
>
>- ret = snprintf(buf, len, "%d", rep->vport - 1);
>- if (ret >= len)
>- return -EOPNOTSUPP;
>+ info->type = NETDEV_PORT_PCI_VF;
NETDEV_PORT_TYPE_PCI_VF
or
NETDEV_PORT_NAME_TYPE_PCI_VF
depends on the option you chose above.
>+ info->pci.vf_id = rep->vport - 1;
>
> return 0;
> }
>diff --git a/drivers/net/ethernet/mellanox/mlxsw/switchx2.c b/drivers/net/ethernet/mellanox/mlxsw/switchx2.c
>index 3b0f72455681..383b8b5f41cf 100644
>--- a/drivers/net/ethernet/mellanox/mlxsw/switchx2.c
>+++ b/drivers/net/ethernet/mellanox/mlxsw/switchx2.c
>@@ -413,15 +413,13 @@ mlxsw_sx_port_get_stats64(struct net_device *dev,
> stats->tx_dropped = tx_dropped;
> }
>
>-static int mlxsw_sx_port_get_phys_port_name(struct net_device *dev, char *name,
>- size_t len)
>+static int mlxsw_sx_port_get_phys_port_name(struct net_device *dev,
>+ struct netdev_port_info *info)
> {
> struct mlxsw_sx_port *mlxsw_sx_port = netdev_priv(dev);
>- int err;
>
>- err = snprintf(name, len, "p%d", mlxsw_sx_port->mapping.module + 1);
>- if (err >= len)
>- return -EINVAL;
>+ info->type = NETDEV_PORT_EXTERNAL;
>+ info->port.id = mlxsw_sx_port->mapping.module + 1;
>
> return 0;
> }
>diff --git a/drivers/net/ethernet/netronome/nfp/nfp_port.c b/drivers/net/ethernet/netronome/nfp/nfp_port.c
>index d16a7b78ba9b..8f5c37b9a79c 100644
>--- a/drivers/net/ethernet/netronome/nfp/nfp_port.c
>+++ b/drivers/net/ethernet/netronome/nfp/nfp_port.c
>@@ -143,11 +143,11 @@ struct nfp_eth_table_port *nfp_port_get_eth_port(struct nfp_port *port)
> }
>
> int
>-nfp_port_get_phys_port_name(struct net_device *netdev, char *name, size_t len)
>+nfp_port_get_phys_port_name(struct net_device *netdev,
>+ struct netdev_port_info *info)
> {
> struct nfp_eth_table_port *eth_port;
> struct nfp_port *port;
>- int n;
>
> port = nfp_port_from_netdev(netdev);
> if (!port)
>@@ -159,25 +159,27 @@ nfp_port_get_phys_port_name(struct net_device *netdev, char *name, size_t len)
> if (!eth_port)
> return -EOPNOTSUPP;
>
>- if (!eth_port->is_split)
>- n = snprintf(name, len, "p%d", eth_port->label_port);
>- else
>- n = snprintf(name, len, "p%ds%d", eth_port->label_port,
>- eth_port->label_subport);
>+ info->type = NETDEV_PORT_EXTERNAL;
>+ info->external.id = eth_port->label_port;
>+
>+ if (eth_port->is_split) {
>+ info->type = NETDEV_PORT_EXTERNAL_SPLIT;
>+ info->external.split_id = eth_port->label_subport;
>+ }
> break;
> case NFP_PORT_PF_PORT:
>- n = snprintf(name, len, "pf%d", port->pf_id);
>+ info->type = NETDEV_PORT_PCI_PF;
>+ info->pci.pf_id = port->pf_id;
> break;
> case NFP_PORT_VF_PORT:
>- n = snprintf(name, len, "pf%dvf%d", port->pf_id, port->vf_id);
>+ info->type = NETDEV_PORT_PCI_VF;
>+ info->pci.pf_id = port->pf_id;
>+ info->pci.vf_id = port->vf_id;
> break;
> default:
> return -EOPNOTSUPP;
> }
>
>- if (n >= len)
>- return -EINVAL;
>-
> return 0;
> }
>
>diff --git a/drivers/net/ethernet/netronome/nfp/nfp_port.h b/drivers/net/ethernet/netronome/nfp/nfp_port.h
>index 56c76926c82a..03b8746feb29 100644
>--- a/drivers/net/ethernet/netronome/nfp/nfp_port.h
>+++ b/drivers/net/ethernet/netronome/nfp/nfp_port.h
>@@ -118,8 +118,8 @@ nfp_port_from_id(struct nfp_pf *pf, enum nfp_port_type type, unsigned int id);
> struct nfp_eth_table_port *__nfp_port_get_eth_port(struct nfp_port *port);
> struct nfp_eth_table_port *nfp_port_get_eth_port(struct nfp_port *port);
>
>-int
>-nfp_port_get_phys_port_name(struct net_device *netdev, char *name, size_t len);
>+int nfp_port_get_phys_port_name(struct net_device *netdev,
>+ struct netdev_port_info *info);
> int nfp_port_configure(struct net_device *netdev, bool configed);
>
> struct nfp_port *
>diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>index 3a3cdc1b1f31..0a055df701ef 100644
>--- a/include/linux/netdevice.h
>+++ b/include/linux/netdevice.h
>@@ -845,6 +845,22 @@ struct xfrmdev_ops {
> };
> #endif
>
>+struct netdev_port_info {
>+ int type;
enum please
>+
>+ union {
>+ struct {
>+ u32 id;
>+ u32 split_id;
>+ } external;
>+
>+ struct {
>+ u32 pf_id;
>+ u32 vf_id;
>+ } pci;
>+ };
>+};
>+
> /*
> * This structure defines the management hooks for network devices.
> * The following hooks can be defined; unless noted otherwise, they are
>@@ -1306,7 +1322,7 @@ struct net_device_ops {
> int (*ndo_get_phys_port_id)(struct net_device *dev,
> struct netdev_phys_item_id *ppid);
> int (*ndo_get_phys_port_name)(struct net_device *dev,
>- char *name, size_t len);
>+ struct netdev_port_info *info);
> void (*ndo_udp_tunnel_add)(struct net_device *dev,
> struct udp_tunnel_info *ti);
> void (*ndo_udp_tunnel_del)(struct net_device *dev,
>diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
>index 8d062c58d5cb..e00ff0333e3f 100644
>--- a/include/uapi/linux/if_link.h
>+++ b/include/uapi/linux/if_link.h
>@@ -158,6 +158,7 @@ enum {
> IFLA_PAD,
> IFLA_XDP,
> IFLA_EVENT,
>+ IFLA_PORT_INFO,
> __IFLA_MAX
> };
>
>@@ -927,4 +928,19 @@ enum {
> IFLA_EVENT_BONDING_OPTIONS, /* change in bonding options */
> };
>
>+enum {
>+ NETDEV_PORT_EXTERNAL,
>+ NETDEV_PORT_EXTERNAL_SPLIT,
>+ NETDEV_PORT_PCI_PF,
Isn't PF also EXTERNAL? Cant VF be split? What I'm getting at, shoudn't
these be flags?
>+ NETDEV_PORT_PCI_VF,
>+};
>+
^ permalink raw reply
* Re: [RFC] switchdev: generate phys_port_name in the core
From: Jiri Pirko @ 2017-07-28 5:58 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Or Gerlitz, netdev, Or Gerlitz, Michael Chan, Sathya Perla,
David Miller, simon.horman
In-Reply-To: <20170728053507.GA1857@nanopsycho>
Fri, Jul 28, 2017 at 07:35:07AM CEST, jiri@resnulli.us wrote:
>Fri, Jul 28, 2017 at 04:31:22AM CEST, jakub.kicinski@netronome.com wrote:
>>On Thu, 27 Jul 2017 13:30:44 +0300, Or Gerlitz wrote:
>>> > want to add port splitting support, for example, reporting the name on
>>> > physical ports will become more of a necessity.
>>>
>>> > If we adopt Jiri's suggestion of returning structured data it will be
>>> > very easy to give user space type and indexes separately, but we should
>>> > probably still return the string for backwards compatibility.
>>>
>>> I am not still clear how the structured data would look like
>>
>>I decided to just quickly write the code, that should be easier to
>>understand. We can probably leave out the netlink part of the API
>>if there is no need for it right now, but that's what I ment by
>>returning the information in a more structured way.
>>
>>Tested-by: nobody :)
>>Suggested-by: Jiri (if I understood correctly)
>
>Yes, you did :) Couple of nits inlined.
>
>
>>---
>> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 8 ++-
>> drivers/net/ethernet/mellanox/mlxsw/switchx2.c | 10 ++--
>> drivers/net/ethernet/netronome/nfp/nfp_port.c | 26 ++++-----
>> drivers/net/ethernet/netronome/nfp/nfp_port.h | 4 +-
>> include/linux/netdevice.h | 18 ++++++-
>> include/uapi/linux/if_link.h | 16 ++++++
>> net/core/dev.c | 31 +++++++++--
>> net/core/rtnetlink.c | 69 ++++++++++++++++++++++++
>> 8 files changed, 153 insertions(+), 29 deletions(-)
>>
>>diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>>index 45e60be9c277..7a71291b8ec3 100644
>>--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>>+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>>@@ -637,16 +637,14 @@ static int mlx5e_rep_close(struct net_device *dev)
>> }
>>
>> static int mlx5e_rep_get_phys_port_name(struct net_device *dev,
>>- char *buf, size_t len)
>>+ struct netdev_port_info *info)
>
>Either we rename ndo to something like ndo_get_port_info or you rename
>the struct to netdev_port_name_info. These 2 should be in sync
As this is strictly related to port name, I think it should be:
struct netdev_phys_port_name_info
And the rest named in-sync with this
^ permalink raw reply
* [PATCH] netfilter: SYNPROXY: fix process non tcp packet bug in {ipv4,ipv6}_synproxy_hook
From: Lin Zhang @ 2017-07-28 6:03 UTC (permalink / raw)
To: davem, pablo, kadlec, fw, kuznet, yoshfuji
Cc: netdev, netfilter-devel, coreteam, Lin Zhang
In function {ipv4,ipv6}_synproxy_hook we expect a normal tcp packet,
but the real server maybe reply an icmp error packet related to the
exist tcp conntrack, so we will access wrong tcp data.
For fix it, we simply pass IP_CT_RELATED_REPLY packets.
Signed-off-by: Lin Zhang <xiaolou4617@gmail.com>
---
net/ipv4/netfilter/ipt_SYNPROXY.c | 2 +-
net/ipv6/netfilter/ip6t_SYNPROXY.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/netfilter/ipt_SYNPROXY.c b/net/ipv4/netfilter/ipt_SYNPROXY.c
index f1528f7..3971fd9 100644
--- a/net/ipv4/netfilter/ipt_SYNPROXY.c
+++ b/net/ipv4/netfilter/ipt_SYNPROXY.c
@@ -330,7 +330,7 @@ static unsigned int ipv4_synproxy_hook(void *priv,
if (synproxy == NULL)
return NF_ACCEPT;
- if (nf_is_loopback_packet(skb))
+ if (nf_is_loopback_packet(skb) || ctinfo == IP_CT_RELATED_REPLY)
return NF_ACCEPT;
thoff = ip_hdrlen(skb);
diff --git a/net/ipv6/netfilter/ip6t_SYNPROXY.c b/net/ipv6/netfilter/ip6t_SYNPROXY.c
index ce203dd..c4bcefe 100644
--- a/net/ipv6/netfilter/ip6t_SYNPROXY.c
+++ b/net/ipv6/netfilter/ip6t_SYNPROXY.c
@@ -347,7 +347,7 @@ static unsigned int ipv6_synproxy_hook(void *priv,
if (synproxy == NULL)
return NF_ACCEPT;
- if (nf_is_loopback_packet(skb))
+ if (nf_is_loopback_packet(skb) || ctinfo == IP_CT_RELATED_REPLY)
return NF_ACCEPT;
nexthdr = ipv6_hdr(skb)->nexthdr;
--
1.8.3.1
^ permalink raw reply related
* Re: After a while of system running no incoming UDP any more?
From: Marc Haber @ 2017-07-28 6:26 UTC (permalink / raw)
To: Paolo Abeni; +Cc: netdev
In-Reply-To: <1500905950.2458.6.camel@redhat.com>
On Mon, Jul 24, 2017 at 04:19:10PM +0200, Paolo Abeni wrote:
> Once that a system enter the buggy status, do the packets reach the
> relevant socket's queue?
>
> ss -u
> nstat |grep -e Udp -e Ip
>
> will help checking that.
I now have the issue on one machine, a Xen guest acting as authoritative
nameserver for my domains. Here are the outputs during normal use, with
artificial queries coming in on eth0:
[9/1075]mh@impetus:~ $ ss -u
Recv-Q Send-Q Local Address:Port Peer Address:Port
0 0 127.0.0.1:56547 127.0.0.1:domain
0 0 216.231.132.60:27667 198.41.0.4:domain
0 0 216.231.132.60:44121 8.8.8.8:domain
0 0 216.231.132.60:29814 198.41.0.4:domain
[10/1076]mh@impetus:~ $ ss -u
Recv-Q Send-Q Local Address:Port Peer Address:Port
[11/1076]mh@impetus:~ $ ss -u
Recv-Q Send-Q Local Address:Port Peer Address:Port
[12/1076]mh@impetus:~ $ ss -u
Recv-Q Send-Q Local Address:Port Peer Address:Port
[13/1076]mh@impetus:~ $ ss -u
Recv-Q Send-Q Local Address:Port Peer Address:Port
[14/1076]mh@impetus:~ $ nstat | grep -e Udp -e Ip
IpInReceives 400688 0.0
IpInAddrErrors 18567 0.0
IpInUnknownProtos 3 0.0
IpInDelivers 330634 0.0
IpOutRequests 283637 0.0
UdpInDatagrams 145860 0.0
UdpNoPorts 1313 0.0
UdpInErrors 9356 0.0
UdpOutDatagrams 153093 0.0
UdpIgnoredMulti 34148 0.0
Ip6InReceives 161178 0.0
Ip6InNoRoutes 8 0.0
Ip6InDelivers 73841 0.0
Ip6OutRequests 77575 0.0
Ip6InMcastPkts 87332 0.0
Ip6OutMcastPkts 109 0.0
Ip6InOctets 21880674 0.0
Ip6OutOctets 9633059 0.0
Ip6InMcastOctets 9371483 0.0
Ip6OutMcastOctets 6636 0.0
Ip6InNoECTPkts 161202 0.0
Ip6InECT1Pkts 15 0.0
Ip6InECT0Pkts 11 0.0
Ip6InCEPkts 4 0.0
Udp6InDatagrams 11725 0.0
Udp6NoPorts 2 0.0
Udp6InErrors 1989 0.0
Udp6OutDatagrams 14483 0.0
IpExtInBcastPkts 34148 0.0
IpExtInOctets 47462716 0.0
IpExtOutOctets 31262696 0.0
IpExtInBcastOctets 7476059 0.0
IpExtInNoECTPkts 400178 0.0
IpExtInECT1Pkts 22 0.0
IpExtInECT0Pkts 481 0.0
IpExtInCEPkts 14 0.0
[15/1077]mh@impetus:~ $ nstat | grep -e Udp -e Ip
IpInReceives 25 0.0
IpInDelivers 25 0.0
IpOutRequests 16 0.0
UdpInDatagrams 1 0.0
UdpInErrors 24 0.0
UdpOutDatagrams 16 0.0
Ip6InReceives 15 0.0
Ip6InDelivers 14 0.0
Ip6OutRequests 12 0.0
Ip6InMcastPkts 1 0.0
Ip6InOctets 1219 0.0
Ip6OutOctets 4384 0.0
Ip6InMcastOctets 131 0.0
Ip6InNoECTPkts 15 0.0
IpExtInOctets 11779 0.0
IpExtOutOctets 1023 0.0
IpExtInNoECTPkts 25 0.0
[16/1077]mh@impetus:~ $ nstat | grep -e Udp -e Ip
IpInReceives 24 0.0
IpInDelivers 24 0.0
IpOutRequests 18 0.0
UdpInErrors 22 0.0
UdpOutDatagrams 16 0.0
Ip6InReceives 15 0.0
Ip6InDelivers 12 0.0
Ip6OutRequests 10 0.0
Ip6InMcastPkts 3 0.0
Ip6InOctets 1160 0.0
Ip6OutOctets 2456 0.0
Ip6InMcastOctets 216 0.0
Ip6InNoECTPkts 15 0.0
IpExtInOctets 8612 0.0
IpExtOutOctets 1127 0.0
IpExtInNoECTPkts 24 0.0
[17/1077]mh@impetus:~ $ nstat | grep -e Udp -e Ip
IpInReceives 5 0.0
IpInDelivers 4 0.0
IpOutRequests 3 0.0
UdpNoPorts 1 0.0
UdpInErrors 2 0.0
UdpOutDatagrams 1 0.0
Ip6InReceives 12 0.0
Ip6InDelivers 12 0.0
Ip6OutRequests 10 0.0
Ip6InOctets 944 0.0
Ip6OutOctets 2364 0.0
Ip6InNoECTPkts 12 0.0
IpExtInOctets 429 0.0
IpExtOutOctets 226 0.0
IpExtInNoECTPkts 5 0.0
[18/1077]mh@impetus:~ $
And here, hopefully a bit more helpful:
[19/1078]mh@impetus:~ $ ss -u ; nstat | grep -e Udp -e Ip ; dig +time=2 @8.8.8.8 zugschlus.de mx ; ss -u ; nstat | grep -e Udp -e Ip
Recv-Q Send-Q Local Address:Port Peer Address:Port
0 0 216.231.132.60:27333 198.41.0.4:domain
0 0 216.231.132.60:38101 198.41.0.4:domain
0 0 216.231.132.60:15836 198.41.0.4:domain
0 0 216.231.132.60:50655 8.8.8.8:domain
0 0 216.231.132.60:41953 198.41.0.4:domain
0 0 216.231.132.60:6888 198.41.0.4:domain
0 0 216.231.132.60:51441 198.41.0.4:domain
0 0 216.231.132.60:42503 198.41.0.4:domain
0 0 216.231.132.60:12575 198.41.0.4:domain
0 0 216.231.132.60:13857 198.41.0.4:domain
0 0 216.231.132.60:16419 192.36.148.17:domain
0 0 216.231.132.60:39227 198.41.0.4:domain
0 0 127.0.0.1:54608 127.0.0.1:domain
0 0 216.231.132.60:20818 198.41.0.4:domain
0 0 216.231.132.60:56662 198.41.0.4:domain
0 0 216.231.132.60:48259 192.36.148.17:domain
0 0 216.231.132.60:37803 198.41.0.4:domain
IpInReceives 59 0.0
IpInAddrErrors 1 0.0
IpInDelivers 56 0.0
IpOutRequests 50 0.0
UdpInDatagrams 1 0.0
UdpInErrors 50 0.0
UdpOutDatagrams 47 0.0
UdpIgnoredMulti 1 0.0
Ip6InReceives 75 0.0
Ip6InDelivers 73 0.0
Ip6OutRequests 64 0.0
Ip6InMcastPkts 2 0.0
Ip6InOctets 7837 0.0
Ip6OutOctets 11876 0.0
Ip6InMcastOctets 279 0.0
Ip6InNoECTPkts 75 0.0
Udp6InErrors 3 0.0
IpExtInBcastPkts 1 0.0
IpExtInOctets 18447 0.0
IpExtOutOctets 3478 0.0
IpExtInBcastOctets 183 0.0
IpExtInNoECTPkts 59 0.0
; <<>> DiG 9.10.3-P4-Debian <<>> +time=2 @8.8.8.8 zugschlus.de mx
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
Recv-Q Send-Q Local Address:Port Peer Address:Port
0 0 216.231.132.60:7879 202.12.27.33:domain
0 0 216.231.132.60:32711 202.12.27.33:domain
0 0 216.231.132.60:54238 202.12.27.33:domain
0 0 216.231.132.60:30948 192.228.79.201:domain
0 0 216.231.132.60:4106 202.12.27.33:domain
0 0 216.231.132.60:6667 202.12.27.33:domain
0 0 216.231.132.60:2090 192.228.79.201:domain
0 0 216.231.132.60:60459 192.228.79.201:domain
0 0 216.231.132.60:16427 202.12.27.33:domain
0 0 216.231.132.60:9019 202.12.27.33:domain
0 0 216.231.132.60:2113 202.12.27.33:domain
0 0 216.231.132.60:34907 202.12.27.33:domain
0 0 216.231.132.60:34654 202.12.27.33:domain
0 0 216.231.132.60:47725 202.12.27.33:domain
0 0 216.231.132.60:35774 202.12.27.33:domain
IpInReceives 38 0.0
IpInDelivers 38 0.0
IpOutRequests 38 0.0
UdpInDatagrams 2 0.0
UdpInErrors 34 0.0
UdpOutDatagrams 36 0.0
Ip6InReceives 14 0.0
Ip6InDelivers 13 0.0
Ip6OutRequests 13 0.0
Ip6InMcastPkts 1 0.0
Ip6InOctets 1046 0.0
Ip6OutOctets 6277 0.0
Ip6InMcastOctets 133 0.0
Ip6InNoECTPkts 13 0.0
Ip6InECT0Pkts 1 0.0
Udp6InDatagrams 1 0.0
Udp6OutDatagrams 1 0.0
IpExtInOctets 15963 0.0
IpExtOutOctets 2397 0.0
IpExtInNoECTPkts 37 0.0
IpExtInECT0Pkts 1 0.0
[20/1079]mh@impetus:~ $
I am afraid I cannot keep this state for much longer than a few
additional hours as this is an authoritative name server...
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply
* Re: TCP fast retransmit issues
From: Klavs Klavsen @ 2017-07-28 6:36 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Eric Dumazet, netdev
In-Reply-To: <20170726143827.GD1737@1wt.eu>
The network guys know what caused it.
Appearently on (atleast some) Cisco equipment the feature:
TCP Sequence Number Randomization
is enabled by default.
It would most definetely be beneficial if Linux handled SACK "not
working" better than it does - but then I might never have found the
culprit who destroyed SACK :)
Willy Tarreau wrote on 26-07-2017 16:38:
> On Wed, Jul 26, 2017 at 04:25:29PM +0200, Klavs Klavsen wrote:
>> Thank you very much guys for your insight.. its highly appreciated.
>>
>> Next up for me, is waiting till the network guys come back from summer
>> vacation, and convince them to sniff on the devices in between to pinpoint
>> the culprit :)
> That said, Eric, I'm a bit surprized that it completely stalls. Shouldn't
> the sender end up retransmitting unacked segments after seeing a certain
> number of ACKs not making progress ? Or maybe this is disabled when SACKs
> are in use but it seems to me that once invalid SACKs are ignored we should
> ideally fall back to the normal way to deal with losses. Here the server
> ACKed 3903858556 for the first time at 15:59:54.292743 and repeated this
> one 850 times till 16:01:17.296407 but the client kept sending past this
> point probably due to a huge window, so this looks suboptimal to me.
>
> Willy
--
Regards,
Klavs Klavsen, GSEC - kl@vsen.dk - http://www.vsen.dk - Tlf. 61281200
"Those who do not understand Unix are condemned to reinvent it, poorly."
--Henry Spencer
^ permalink raw reply
* Re: [PATCH v2 05/11] net: stmmac: dwmac-rk: Add internal phy support
From: David.Wu @ 2017-07-28 6:46 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, heiko, f.fainelli, robh+dt, mark.rutland, catalin.marinas,
will.deacon, olof, linux, arnd, peppe.cavallaro, alexandre.torgue,
huangtao, hwg, netdev, linux-arm-kernel, linux-rockchip,
devicetree, linux-kernel
In-Reply-To: <20170727134834.GD18666@lunn.ch>
Hi Andrew,
在 2017/7/27 21:48, Andrew Lunn 写道:
> I think we need to discuss this. This PHY appears to be on an MDIO
> bus, it uses a standard PHY driver, and it appears to be using an RMII
> interface. So it is just an ordinary PHY.
>
> Internal is supposed to be something which is not ordinary, does not
> use one of the standard phy modes, needs something special to make it
> work.
Yes, it is a ordinary PHY in fact, using MDIO bus, but it is a internal
phy inside Soc, so the "internal" is not the internal as Florain said.
^ permalink raw reply
* Re: TCP fast retransmit issues
From: Christoph Paasch @ 2017-07-28 6:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Willy Tarreau, Klavs Klavsen, netdev
In-Reply-To: <1501079532.12695.17.camel@edumazet-glaptop3.roam.corp.google.com>
Hello,
On Wed, Jul 26, 2017 at 7:32 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2017-07-26 at 15:42 +0200, Willy Tarreau wrote:
>> On Wed, Jul 26, 2017 at 06:31:21AM -0700, Eric Dumazet wrote:
>> > On Wed, 2017-07-26 at 14:18 +0200, Klavs Klavsen wrote:
>> > > the 192.168.32.44 is a Centos 7 box.
>> >
>> > Could you grab a capture on this box, to see if the bogus packets are
>> > sent by it, or later mangled by a middle box ?
>>
>> Given the huge difference between the window and the ranges of the
>> values in the SACK field, I'm pretty sure there's a firewall doing
>> some sequence numbers randomization in the middle, not aware of SACK
>> and not converting these ones. I've had to disable such broken
>> features more than once in field after similar observations! Probably
>> that the Mac doesn't advertise SACK support and doesn't experience the
>> problem.
>
> We need to check RFC if such invalid SACK blocks should be ignored (DUP
> ACK would be processed and trigger fast retransmit anyway), or strongly
> validated (as I suspect we currently do), leading to a total freeze.
quite some time ago this issue with sequence number randomizing
middleboxes came already up
(http://marc.info/?l=netfilter-devel&m=137691623129822&w=2). From what
I remember, the RFC does not say that invalid SACK blocks should be
strongly validated. So, trigger dup-ack retransmission seems fine.
I had some patches at the time that ignored invalid sack-blocks and
allowed fast-retransmit to happen thanks to the duplicate acks:
https://patchwork.ozlabs.org/patch/268297/
https://patchwork.ozlabs.org/patch/268298/
Cheers,
Christoph
^ permalink raw reply
* Re: [PATCH v2 05/11] net: stmmac: dwmac-rk: Add internal phy support
From: David.Wu @ 2017-07-28 6:56 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn
Cc: davem, heiko, robh+dt, mark.rutland, catalin.marinas, will.deacon,
olof, linux, arnd, peppe.cavallaro, alexandre.torgue, huangtao,
hwg, netdev, linux-arm-kernel, linux-rockchip, devicetree,
linux-kernel
In-Reply-To: <65ae1747-4dff-b1d8-8aa3-684fc8c7809a@gmail.com>
Hi Florian,
在 2017/7/28 0:54, Florian Fainelli 写道:
> - if you need knowledge about this PHY connection type prior to binding
> the PHY device and its driver (that is, before of_phy_connect()) we
> could add a boolean property e.g: "phy-is-internal" that allows us to
> know that, or we can have a new phy-mode value, e.g: "internal-rmii"
> which describes that, either way would probably be fine, but the former
> scales better
>
Using "phy-is-internal" is very helpful, but it is easy to confuse with
the real internal PHY, may we use the other words like phy is inlined🙂.
> Then again, using phy-mode = "internal" even though this is Reduced MII
> is not big of a deal IMHO as long as there is no loss of information and
> that internal de-facto means internal reduced MII for instance.
> --
^ permalink raw reply
* [net-next] igb: add function to get maximum RSS queues
From: Zhang Shengju @ 2017-07-28 7:03 UTC (permalink / raw)
To: jeffrey.t.kirsher, netdev
This patch adds a new function igb_get_max_rss_queues() to get maximum
RSS queues, this will reduce duplicate code and facilitate future
maintenance.
Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
---
drivers/net/ethernet/intel/igb/igb.h | 1 +
drivers/net/ethernet/intel/igb/igb_ethtool.c | 32 +---------------------------
drivers/net/ethernet/intel/igb/igb_main.c | 12 +++++++++--
3 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index 06ffb2b..ca94eff 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -684,6 +684,7 @@ void igb_ptp_rx_pktstamp(struct igb_q_vector *q_vector, void *va,
int igb_ptp_set_ts_config(struct net_device *netdev, struct ifreq *ifr);
int igb_ptp_get_ts_config(struct net_device *netdev, struct ifreq *ifr);
void igb_set_flag_queue_pairs(struct igb_adapter *, const u32);
+unsigned int igb_get_max_rss_queues(struct igb_adapter *);
#ifdef CONFIG_IGB_HWMON
void igb_sysfs_exit(struct igb_adapter *adapter);
int igb_sysfs_init(struct igb_adapter *adapter);
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index d06a8db..606e676 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -3338,37 +3338,7 @@ static int igb_set_rxfh(struct net_device *netdev, const u32 *indir,
static unsigned int igb_max_channels(struct igb_adapter *adapter)
{
- struct e1000_hw *hw = &adapter->hw;
- unsigned int max_combined = 0;
-
- switch (hw->mac.type) {
- case e1000_i211:
- max_combined = IGB_MAX_RX_QUEUES_I211;
- break;
- case e1000_82575:
- case e1000_i210:
- max_combined = IGB_MAX_RX_QUEUES_82575;
- break;
- case e1000_i350:
- if (!!adapter->vfs_allocated_count) {
- max_combined = 1;
- break;
- }
- /* fall through */
- case e1000_82576:
- if (!!adapter->vfs_allocated_count) {
- max_combined = 2;
- break;
- }
- /* fall through */
- case e1000_82580:
- case e1000_i354:
- default:
- max_combined = IGB_MAX_RX_QUEUES;
- break;
- }
-
- return max_combined;
+ return igb_get_max_rss_queues(adapter);
}
static void igb_get_channels(struct net_device *netdev,
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index ec62410..e6cc6b5 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3026,10 +3026,10 @@ static void igb_probe_vfs(struct igb_adapter *adapter)
#endif /* CONFIG_PCI_IOV */
}
-static void igb_init_queue_configuration(struct igb_adapter *adapter)
+unsigned int igb_get_max_rss_queues(struct igb_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
- u32 max_rss_queues;
+ unsigned int max_rss_queues;
/* Determine the maximum number of RSS queues supported. */
switch (hw->mac.type) {
@@ -3060,6 +3060,14 @@ static void igb_init_queue_configuration(struct igb_adapter *adapter)
break;
}
+ return max_rss_queues;
+}
+
+static void igb_init_queue_configuration(struct igb_adapter *adapter)
+{
+ u32 max_rss_queues;
+
+ max_rss_queues = igb_get_max_rss_queues(adapter);
adapter->rss_queues = min_t(u32, max_rss_queues, num_online_cpus());
igb_set_flag_queue_pairs(adapter, max_rss_queues);
--
1.8.3.1
^ permalink raw reply related
* (unknown),
From: doctornina @ 2017-07-28 7:17 UTC (permalink / raw)
To: netdev
[-- Attachment #1: EMAIL_47501615459_netdev.zip --]
[-- Type: application/zip, Size: 2727 bytes --]
^ permalink raw reply
* Re: [RFC] switchdev: generate phys_port_name in the core
From: Jakub Kicinski @ 2017-07-28 7:27 UTC (permalink / raw)
To: Jiri Pirko
Cc: Or Gerlitz, netdev, Or Gerlitz, Michael Chan, Sathya Perla,
David Miller, simon.horman
In-Reply-To: <20170728053507.GA1857@nanopsycho>
On Fri, 28 Jul 2017 07:35:07 +0200, Jiri Pirko wrote:
> >+enum {
> >+ NETDEV_PORT_EXTERNAL,
> >+ NETDEV_PORT_EXTERNAL_SPLIT,
> >+ NETDEV_PORT_PCI_PF,
>
> Isn't PF also EXTERNAL? Cant VF be split? What I'm getting at, shoudn't
> these be flags?
By external PF do you mean not connected to the current host? Yes we
could make a flag like that. Right now I have picked "external" to
avoid too specific names like MAC/PHY/Ethernet... There could be a
MAC-to-MAC connection for instance, so no PHY involved. Should we go
with NETDEV_PORT_ETH?
I will make SPLIT into a flag.
^ permalink raw reply
* Re: TCP fast retransmit issues
From: Willy Tarreau @ 2017-07-28 7:27 UTC (permalink / raw)
To: Klavs Klavsen; +Cc: Eric Dumazet, netdev
In-Reply-To: <0d41553d-69ac-651c-9c41-743391619a40@vsen.dk>
On Fri, Jul 28, 2017 at 08:36:49AM +0200, Klavs Klavsen wrote:
> The network guys know what caused it.
>
> Appearently on (atleast some) Cisco equipment the feature:
>
> TCP Sequence Number Randomization
>
> is enabled by default.
I didn't want to suggest names but since you did it first ;-) Indeed it's
mostly on the same device that I've been bothered a lot by their annoying
randomization. I used to know by memory the exact command to type to disable
it, but I don't anymore (something along "no randomization"). The other
trouble it causes is retransmits of the first SYN when your source ports
wrap too fast (ie when installed after a proxy). The SYNs reaching the
other end find a session in TIME_WAIT, but the SYN sometimes lands in
the previous window and leads to an ACK instead of a SYN-ACK, which the
firewall blocks. This was easily worked around using timestamps on both
sides thanks to PAWS. But disabling the broken feature is better. And no,
"more secure" is not an excuse for "broken".
> It would most definetely be beneficial if Linux handled SACK "not working"
> better than it does - but then I might never have found the culprit who
> destroyed SACK :)
Yep ;-)
Willy
^ permalink raw reply
* Re: [RFC] switchdev: generate phys_port_name in the core
From: Jakub Kicinski @ 2017-07-28 7:28 UTC (permalink / raw)
To: Jiri Pirko
Cc: Or Gerlitz, netdev, Or Gerlitz, Michael Chan, Sathya Perla,
David Miller, simon.horman
In-Reply-To: <20170728055815.GB1857@nanopsycho>
On Fri, 28 Jul 2017 07:58:15 +0200, Jiri Pirko wrote:
> Fri, Jul 28, 2017 at 07:35:07AM CEST, jiri@resnulli.us wrote:
> >Fri, Jul 28, 2017 at 04:31:22AM CEST, jakub.kicinski@netronome.com wrote:
> >>On Thu, 27 Jul 2017 13:30:44 +0300, Or Gerlitz wrote:
> >>> > want to add port splitting support, for example, reporting the name on
> >>> > physical ports will become more of a necessity.
> >>>
> >>> > If we adopt Jiri's suggestion of returning structured data it will be
> >>> > very easy to give user space type and indexes separately, but we should
> >>> > probably still return the string for backwards compatibility.
> >>>
> >>> I am not still clear how the structured data would look like
> >>
> >>I decided to just quickly write the code, that should be easier to
> >>understand. We can probably leave out the netlink part of the API
> >>if there is no need for it right now, but that's what I ment by
> >>returning the information in a more structured way.
> >>
> >>Tested-by: nobody :)
> >>Suggested-by: Jiri (if I understood correctly)
> >
> >Yes, you did :) Couple of nits inlined.
> >
> >
> >>---
> >> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 8 ++-
> >> drivers/net/ethernet/mellanox/mlxsw/switchx2.c | 10 ++--
> >> drivers/net/ethernet/netronome/nfp/nfp_port.c | 26 ++++-----
> >> drivers/net/ethernet/netronome/nfp/nfp_port.h | 4 +-
> >> include/linux/netdevice.h | 18 ++++++-
> >> include/uapi/linux/if_link.h | 16 ++++++
> >> net/core/dev.c | 31 +++++++++--
> >> net/core/rtnetlink.c | 69 ++++++++++++++++++++++++
> >> 8 files changed, 153 insertions(+), 29 deletions(-)
> >>
> >>diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
> >>index 45e60be9c277..7a71291b8ec3 100644
> >>--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
> >>+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
> >>@@ -637,16 +637,14 @@ static int mlx5e_rep_close(struct net_device *dev)
> >> }
> >>
> >> static int mlx5e_rep_get_phys_port_name(struct net_device *dev,
> >>- char *buf, size_t len)
> >>+ struct netdev_port_info *info)
> >
> >Either we rename ndo to something like ndo_get_port_info or you rename
> >the struct to netdev_port_name_info. These 2 should be in sync
>
> As this is strictly related to port name, I think it should be:
> struct netdev_phys_port_name_info
>
> And the rest named in-sync with this
Hm.. Since we would return the type and IDs via netlink, I was
actually leaning towards ndo_get_port_info. "Name" somehow implies a
string in my mind. Perhaps the "info" part is where I went wrong, could
we go with netdev_port_label? Or netdev_port_ident? I would also
prefer to avoid the phys in name, since it doesn't sit well with PFs
vs VFs.
Ah, naming things...
^ permalink raw reply
* Re: [PATCH v2 05/11] net: stmmac: dwmac-rk: Add internal phy support
From: Maxime Ripard @ 2017-07-28 7:39 UTC (permalink / raw)
To: Corentin Labbe
Cc: Florian Fainelli, mark.rutland-5wv7dgnIgG8, Andrew Lunn,
hwg-TNX95d0MmH7DzftRWevZcw, huangtao-TNX95d0MmH7DzftRWevZcw,
heiko-4mtYJXux2i+zQB+pC5nmwQ, arnd-r2nGTMty4D4,
devicetree-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, will.deacon-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, David Wu,
olof-nZhT3qVonbNeoWH0uzbU5w, peppe.cavallaro-qxv4g6HH51o,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
alexandre.torgue-qxv4g6HH51o
In-Reply-To: <20170727173152.GA16362@Red>
[-- Attachment #1: Type: text/plain, Size: 2990 bytes --]
On Thu, Jul 27, 2017 at 07:31:52PM +0200, Corentin Labbe wrote:
> On Thu, Jul 27, 2017 at 09:54:01AM -0700, Florian Fainelli wrote:
> > On 07/27/2017 06:48 AM, Andrew Lunn wrote:
> > > On Thu, Jul 27, 2017 at 09:02:16PM +0800, David Wu wrote:
> > >> To make internal phy work, need to configure the phy_clock,
> > >> phy cru_reset and related registers.
> > >>
> > >> Signed-off-by: David Wu <david.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> > >> ---
> > >> changes in v2:
> > >> - Use the standard "phy-mode" property for internal phy. (Florian)
> > >
> > > I think we need to discuss this. This PHY appears to be on an MDIO
> > > bus, it uses a standard PHY driver, and it appears to be using an RMII
> > > interface. So it is just an ordinary PHY.
> >
> > First, the fact that the internal PHY also appears through MDIO is
> > orthogonal to the fact that it is internal or external. Plenty of
> > designs have internal PHYs exposed through MDIO because that is
> > convenient. What matters though is how the data/clock lines are wired
> > internally, which is what "phy-mode" describes.
> >
> > >
> > > Internal is supposed to be something which is not ordinary, does not
> > > use one of the standard phy modes, needs something special to make it
> > > work.
> > >
> > > Florain, it appears to be your suggestion to use internal. What do you
> > > say?
> >
> > phy-mode = "internal" really means that it is not a standard MII variant
> > to connect the data/clock lines between the Ethernet MAC and the PHY,
> > and this can happen in some designs (although quite unlikely). So from
> > there we could do several things depending on the requirements:
> >
> > - if you can have your Ethernet MAC driver perform the necessary
> > configuration *after* you have been able to bind the PHY device with its
> > PHY driver, then the PHY driver should have PHY_IS_INTERNAL in its
> > flags, and you can use phy_is_internal() from PHYLIB to tell you that
> > and we could imagine using: phy-mode = "rmii" because that would not too
> > much of a stretch
> >
> > - if you need knowledge about this PHY connection type prior to binding
> > the PHY device and its driver (that is, before of_phy_connect()) we
> > could add a boolean property e.g: "phy-is-internal" that allows us to
> > know that, or we can have a new phy-mode value, e.g: "internal-rmii"
> > which describes that, either way would probably be fine, but the former
> > scales better
>
> We have the same problem on Allwinner SoCs for dwmac-sun8i, we need
> to set a syscon for chossing between internal/external PHY.
>
> Having this phy-is-internal would be very helpfull. (adding
> internal-xmii will add too many flags in our case)
In our case, we'll always have a phy node, so we can have a compatible
that will give you the same information.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/11] net: phy: Add rockchip phy driver support
From: David.Wu @ 2017-07-28 7:48 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, heiko-4mtYJXux2i+zQB+pC5nmwQ,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, olof-nZhT3qVonbNeoWH0uzbU5w,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, arnd-r2nGTMty4D4,
peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
huangtao-TNX95d0MmH7DzftRWevZcw, hwg-TNX95d0MmH7DzftRWevZcw,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170727133800.GC18666-g2DYL2Zd6BY@public.gmane.org>
Hi Andrew,
在 2017/7/27 21:38, Andrew Lunn 写道:
>> + /*
>> + * If mode switch happens from 10BT to 100BT, all DSP/AFE
>> + * registers are set to default values. So any AFE/DSP
>> + * registers have to be re-initialized in this case.
>> + */
>
> Hi David
>
> Are they also lost on suspend and resume?
Yes, i will add the re-initialized on suspend and resume，and thank you！
>
> Andrew
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: After a while of system running no incoming UDP any more?
From: Eric Dumazet @ 2017-07-28 8:05 UTC (permalink / raw)
To: Marc Haber; +Cc: Paolo Abeni, netdev
In-Reply-To: <20170728062644.bp7agcf6bh7g6yfw@torres.zugschlus.de>
On Fri, 2017-07-28 at 08:26 +0200, Marc Haber wrote:
> On Mon, Jul 24, 2017 at 04:19:10PM +0200, Paolo Abeni wrote:
> > Once that a system enter the buggy status, do the packets reach the
> > relevant socket's queue?
> >
> > ss -u
> > nstat |grep -e Udp -e Ip
> >
> > will help checking that.
>
> I now have the issue on one machine, a Xen guest acting as authoritative
> nameserver for my domains. Here are the outputs during normal use, with
> artificial queries coming in on eth0:
>
> [9/1075]mh@impetus:~ $ ss -u
> Recv-Q Send-Q Local Address:Port Peer Address:Port
> 0 0 127.0.0.1:56547 127.0.0.1:domain
> 0 0 216.231.132.60:27667 198.41.0.4:domain
> 0 0 216.231.132.60:44121 8.8.8.8:domain
> 0 0 216.231.132.60:29814 198.41.0.4:domain
> [10/1076]mh@impetus:~ $ ss -u
> Recv-Q Send-Q Local Address:Port Peer Address:Port
> [11/1076]mh@impetus:~ $ ss -u
> Recv-Q Send-Q Local Address:Port Peer Address:Port
> [12/1076]mh@impetus:~ $ ss -u
> Recv-Q Send-Q Local Address:Port Peer Address:Port
> [13/1076]mh@impetus:~ $ ss -u
> Recv-Q Send-Q Local Address:Port Peer Address:Port
> [14/1076]mh@impetus:~ $ nstat | grep -e Udp -e Ip
> IpInReceives 400688 0.0
> IpInAddrErrors 18567 0.0
> IpInUnknownProtos 3 0.0
> IpInDelivers 330634 0.0
> IpOutRequests 283637 0.0
> UdpInDatagrams 145860 0.0
> UdpNoPorts 1313 0.0
> UdpInErrors 9356 0.0
> UdpOutDatagrams 153093 0.0
> UdpIgnoredMulti 34148 0.0
> Ip6InReceives 161178 0.0
> Ip6InNoRoutes 8 0.0
> Ip6InDelivers 73841 0.0
> Ip6OutRequests 77575 0.0
> Ip6InMcastPkts 87332 0.0
> Ip6OutMcastPkts 109 0.0
> Ip6InOctets 21880674 0.0
> Ip6OutOctets 9633059 0.0
> Ip6InMcastOctets 9371483 0.0
> Ip6OutMcastOctets 6636 0.0
> Ip6InNoECTPkts 161202 0.0
> Ip6InECT1Pkts 15 0.0
> Ip6InECT0Pkts 11 0.0
> Ip6InCEPkts 4 0.0
> Udp6InDatagrams 11725 0.0
> Udp6NoPorts 2 0.0
> Udp6InErrors 1989 0.0
> Udp6OutDatagrams 14483 0.0
> IpExtInBcastPkts 34148 0.0
> IpExtInOctets 47462716 0.0
> IpExtOutOctets 31262696 0.0
> IpExtInBcastOctets 7476059 0.0
> IpExtInNoECTPkts 400178 0.0
> IpExtInECT1Pkts 22 0.0
> IpExtInECT0Pkts 481 0.0
> IpExtInCEPkts 14 0.0
> [15/1077]mh@impetus:~ $ nstat | grep -e Udp -e Ip
> IpInReceives 25 0.0
> IpInDelivers 25 0.0
> IpOutRequests 16 0.0
> UdpInDatagrams 1 0.0
> UdpInErrors 24 0.0
> UdpOutDatagrams 16 0.0
> Ip6InReceives 15 0.0
> Ip6InDelivers 14 0.0
> Ip6OutRequests 12 0.0
> Ip6InMcastPkts 1 0.0
> Ip6InOctets 1219 0.0
> Ip6OutOctets 4384 0.0
> Ip6InMcastOctets 131 0.0
> Ip6InNoECTPkts 15 0.0
> IpExtInOctets 11779 0.0
> IpExtOutOctets 1023 0.0
> IpExtInNoECTPkts 25 0.0
> [16/1077]mh@impetus:~ $ nstat | grep -e Udp -e Ip
> IpInReceives 24 0.0
> IpInDelivers 24 0.0
> IpOutRequests 18 0.0
> UdpInErrors 22 0.0
> UdpOutDatagrams 16 0.0
> Ip6InReceives 15 0.0
> Ip6InDelivers 12 0.0
> Ip6OutRequests 10 0.0
> Ip6InMcastPkts 3 0.0
> Ip6InOctets 1160 0.0
> Ip6OutOctets 2456 0.0
> Ip6InMcastOctets 216 0.0
> Ip6InNoECTPkts 15 0.0
> IpExtInOctets 8612 0.0
> IpExtOutOctets 1127 0.0
> IpExtInNoECTPkts 24 0.0
> [17/1077]mh@impetus:~ $ nstat | grep -e Udp -e Ip
> IpInReceives 5 0.0
> IpInDelivers 4 0.0
> IpOutRequests 3 0.0
> UdpNoPorts 1 0.0
> UdpInErrors 2 0.0
> UdpOutDatagrams 1 0.0
> Ip6InReceives 12 0.0
> Ip6InDelivers 12 0.0
> Ip6OutRequests 10 0.0
> Ip6InOctets 944 0.0
> Ip6OutOctets 2364 0.0
> Ip6InNoECTPkts 12 0.0
> IpExtInOctets 429 0.0
> IpExtOutOctets 226 0.0
> IpExtInNoECTPkts 5 0.0
> [18/1077]mh@impetus:~ $
>
> And here, hopefully a bit more helpful:
>
> [19/1078]mh@impetus:~ $ ss -u ; nstat | grep -e Udp -e Ip ; dig +time=2 @8.8.8.8 zugschlus.de mx ; ss -u ; nstat | grep -e Udp -e Ip
> Recv-Q Send-Q Local Address:Port Peer Address:Port
> 0 0 216.231.132.60:27333 198.41.0.4:domain
> 0 0 216.231.132.60:38101 198.41.0.4:domain
> 0 0 216.231.132.60:15836 198.41.0.4:domain
> 0 0 216.231.132.60:50655 8.8.8.8:domain
> 0 0 216.231.132.60:41953 198.41.0.4:domain
> 0 0 216.231.132.60:6888 198.41.0.4:domain
> 0 0 216.231.132.60:51441 198.41.0.4:domain
> 0 0 216.231.132.60:42503 198.41.0.4:domain
> 0 0 216.231.132.60:12575 198.41.0.4:domain
> 0 0 216.231.132.60:13857 198.41.0.4:domain
> 0 0 216.231.132.60:16419 192.36.148.17:domain
> 0 0 216.231.132.60:39227 198.41.0.4:domain
> 0 0 127.0.0.1:54608 127.0.0.1:domain
> 0 0 216.231.132.60:20818 198.41.0.4:domain
> 0 0 216.231.132.60:56662 198.41.0.4:domain
> 0 0 216.231.132.60:48259 192.36.148.17:domain
> 0 0 216.231.132.60:37803 198.41.0.4:domain
> IpInReceives 59 0.0
> IpInAddrErrors 1 0.0
> IpInDelivers 56 0.0
> IpOutRequests 50 0.0
> UdpInDatagrams 1 0.0
> UdpInErrors 50 0.0
> UdpOutDatagrams 47 0.0
> UdpIgnoredMulti 1 0.0
> Ip6InReceives 75 0.0
> Ip6InDelivers 73 0.0
> Ip6OutRequests 64 0.0
> Ip6InMcastPkts 2 0.0
> Ip6InOctets 7837 0.0
> Ip6OutOctets 11876 0.0
> Ip6InMcastOctets 279 0.0
> Ip6InNoECTPkts 75 0.0
> Udp6InErrors 3 0.0
> IpExtInBcastPkts 1 0.0
> IpExtInOctets 18447 0.0
> IpExtOutOctets 3478 0.0
> IpExtInBcastOctets 183 0.0
> IpExtInNoECTPkts 59 0.0
>
> ; <<>> DiG 9.10.3-P4-Debian <<>> +time=2 @8.8.8.8 zugschlus.de mx
> ; (1 server found)
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> Recv-Q Send-Q Local Address:Port Peer Address:Port
> 0 0 216.231.132.60:7879 202.12.27.33:domain
> 0 0 216.231.132.60:32711 202.12.27.33:domain
> 0 0 216.231.132.60:54238 202.12.27.33:domain
> 0 0 216.231.132.60:30948 192.228.79.201:domain
> 0 0 216.231.132.60:4106 202.12.27.33:domain
> 0 0 216.231.132.60:6667 202.12.27.33:domain
> 0 0 216.231.132.60:2090 192.228.79.201:domain
> 0 0 216.231.132.60:60459 192.228.79.201:domain
> 0 0 216.231.132.60:16427 202.12.27.33:domain
> 0 0 216.231.132.60:9019 202.12.27.33:domain
> 0 0 216.231.132.60:2113 202.12.27.33:domain
> 0 0 216.231.132.60:34907 202.12.27.33:domain
> 0 0 216.231.132.60:34654 202.12.27.33:domain
> 0 0 216.231.132.60:47725 202.12.27.33:domain
> 0 0 216.231.132.60:35774 202.12.27.33:domain
> IpInReceives 38 0.0
> IpInDelivers 38 0.0
> IpOutRequests 38 0.0
> UdpInDatagrams 2 0.0
> UdpInErrors 34 0.0
> UdpOutDatagrams 36 0.0
> Ip6InReceives 14 0.0
> Ip6InDelivers 13 0.0
> Ip6OutRequests 13 0.0
> Ip6InMcastPkts 1 0.0
> Ip6InOctets 1046 0.0
> Ip6OutOctets 6277 0.0
> Ip6InMcastOctets 133 0.0
> Ip6InNoECTPkts 13 0.0
> Ip6InECT0Pkts 1 0.0
> Udp6InDatagrams 1 0.0
> Udp6OutDatagrams 1 0.0
> IpExtInOctets 15963 0.0
> IpExtOutOctets 2397 0.0
> IpExtInNoECTPkts 37 0.0
> IpExtInECT0Pkts 1 0.0
> [20/1079]mh@impetus:~ $
>
> I am afraid I cannot keep this state for much longer than a few
> additional hours as this is an authoritative name server...
>
> Greetings
> Marc
>
To confirm the refcount issue, you might send us :
cat /proc/net/udp6
Normally, the refcount column should have a value of 2
^ permalink raw reply
* Re: After a while of system running no incoming UDP any more?
From: Paolo Abeni @ 2017-07-28 8:07 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
In-Reply-To: <20170728062644.bp7agcf6bh7g6yfw@torres.zugschlus.de>
Hi,
On Fri, 2017-07-28 at 08:26 +0200, Marc Haber wrote:
> On Mon, Jul 24, 2017 at 04:19:10PM +0200, Paolo Abeni wrote:
> > Once that a system enter the buggy status, do the packets reach the
> > relevant socket's queue?
> >
> > ss -u
> > nstat |grep -e Udp -e Ip
> >
> > will help checking that.
>
> I now have the issue on one machine, a Xen guest acting as authoritative
> nameserver for my domains. Here are the outputs during normal use, with
> artificial queries coming in on eth0:
>
> [9/1075]mh@impetus:~ $ ss -u
> Recv-Q Send-Q Local Address:Port Peer Address:Port
> 0 0 127.0.0.1:56547 127.0.0.1:domain
> 0 0 216.231.132.60:27667 198.41.0.4:domain
> 0 0 216.231.132.60:44121 8.8.8.8:domain
> 0 0 216.231.132.60:29814 198.41.0.4:domain
> [10/1076]mh@impetus:~ $ ss -u
> Recv-Q Send-Q Local Address:Port Peer Address:Port
> [11/1076]mh@impetus:~ $ ss -u
> Recv-Q Send-Q Local Address:Port Peer Address:Port
> [12/1076]mh@impetus:~ $ ss -u
> Recv-Q Send-Q Local Address:Port Peer Address:Port
> [13/1076]mh@impetus:~ $ ss -u
> Recv-Q Send-Q Local Address:Port Peer Address:Port
> [14/1076]mh@impetus:~ $ nstat | grep -e Udp -e Ip
> IpInReceives 400688 0.0
> IpInAddrErrors 18567 0.0
> IpInUnknownProtos 3 0.0
> IpInDelivers 330634 0.0
> IpOutRequests 283637 0.0
> UdpInDatagrams 145860 0.0
> UdpNoPorts 1313 0.0
> UdpInErrors 9356 0.0
Thanks for the info. This is compatible with what reported on:
https://bugzilla.kernel.org/show_bug.cgi?id=196469
and should be fixed by this patch:
http://marc.info/?l=linux-netdev&m=150115960024825&w=2
(approval pending)
Ad a workaround you can disable UDP early demux:
echo 0 > /proc/sys/net/ipv4/udp_early_demux
(will affect both ipv4 and ipv6).
and (if the system is already into the bad state) increase the udp
accounted memory limit, writing in /proc/sys/net/ipv4/udp_mem greater
values than the current ones (the actual values depends on the system
total memory).
Feel free to test the above patch on your systems.
Cheers,
Paolo
^ permalink raw reply
* Re: After a while of system running no incoming UDP any more?
From: Paolo Abeni @ 2017-07-28 8:15 UTC (permalink / raw)
To: Eric Dumazet, Marc Haber; +Cc: netdev
In-Reply-To: <1501229105.12695.23.camel@edumazet-glaptop3.roam.corp.google.com>
Hi,
On Fri, 2017-07-28 at 01:05 -0700, Eric Dumazet wrote:
> On Fri, 2017-07-28 at 08:26 +0200, Marc Haber wrote:
> > On Mon, Jul 24, 2017 at 04:19:10PM +0200, Paolo Abeni wrote:
> > > Once that a system enter the buggy status, do the packets reach the
> > > relevant socket's queue?
> > >
> > > ss -u
> > > nstat |grep -e Udp -e Ip
> > >
> > > will help checking that.
> >
> > I now have the issue on one machine, a Xen guest acting as authoritative
> > nameserver for my domains. Here are the outputs during normal use, with
> > artificial queries coming in on eth0:
> >
> > [9/1075]mh@impetus:~ $ ss -u
> > Recv-Q Send-Q Local Address:Port Peer Address:Port
> > 0 0 127.0.0.1:56547 127.0.0.1:domain
> > 0 0 216.231.132.60:27667 198.41.0.4:domain
> > 0 0 216.231.132.60:44121 8.8.8.8:domain
> > 0 0 216.231.132.60:29814 198.41.0.4:domain
> > [10/1076]mh@impetus:~ $ ss -u
> > Recv-Q Send-Q Local Address:Port Peer Address:Port
> > [11/1076]mh@impetus:~ $ ss -u
> > Recv-Q Send-Q Local Address:Port Peer Address:Port
> > [12/1076]mh@impetus:~ $ ss -u
> > Recv-Q Send-Q Local Address:Port Peer Address:Port
> > [13/1076]mh@impetus:~ $ ss -u
> > Recv-Q Send-Q Local Address:Port Peer Address:Port
> > [14/1076]mh@impetus:~ $ nstat | grep -e Udp -e Ip
> > IpInReceives 400688 0.0
> > IpInAddrErrors 18567 0.0
> > IpInUnknownProtos 3 0.0
> > IpInDelivers 330634 0.0
> > IpOutRequests 283637 0.0
> > UdpInDatagrams 145860 0.0
> > UdpNoPorts 1313 0.0
> > UdpInErrors 9356 0.0
> > UdpOutDatagrams 153093 0.0
> > UdpIgnoredMulti 34148 0.0
> > Ip6InReceives 161178 0.0
> > Ip6InNoRoutes 8 0.0
> > Ip6InDelivers 73841 0.0
> > Ip6OutRequests 77575 0.0
> > Ip6InMcastPkts 87332 0.0
> > Ip6OutMcastPkts 109 0.0
> > Ip6InOctets 21880674 0.0
> > Ip6OutOctets 9633059 0.0
> > Ip6InMcastOctets 9371483 0.0
> > Ip6OutMcastOctets 6636 0.0
> > Ip6InNoECTPkts 161202 0.0
> > Ip6InECT1Pkts 15 0.0
> > Ip6InECT0Pkts 11 0.0
> > Ip6InCEPkts 4 0.0
> > Udp6InDatagrams 11725 0.0
> > Udp6NoPorts 2 0.0
> > Udp6InErrors 1989 0.0
> > Udp6OutDatagrams 14483 0.0
> > IpExtInBcastPkts 34148 0.0
> > IpExtInOctets 47462716 0.0
> > IpExtOutOctets 31262696 0.0
> > IpExtInBcastOctets 7476059 0.0
> > IpExtInNoECTPkts 400178 0.0
> > IpExtInECT1Pkts 22 0.0
> > IpExtInECT0Pkts 481 0.0
> > IpExtInCEPkts 14 0.0
> > [15/1077]mh@impetus:~ $ nstat | grep -e Udp -e Ip
> > IpInReceives 25 0.0
> > IpInDelivers 25 0.0
> > IpOutRequests 16 0.0
> > UdpInDatagrams 1 0.0
> > UdpInErrors 24 0.0
> > UdpOutDatagrams 16 0.0
> > Ip6InReceives 15 0.0
> > Ip6InDelivers 14 0.0
> > Ip6OutRequests 12 0.0
> > Ip6InMcastPkts 1 0.0
> > Ip6InOctets 1219 0.0
> > Ip6OutOctets 4384 0.0
> > Ip6InMcastOctets 131 0.0
> > Ip6InNoECTPkts 15 0.0
> > IpExtInOctets 11779 0.0
> > IpExtOutOctets 1023 0.0
> > IpExtInNoECTPkts 25 0.0
> > [16/1077]mh@impetus:~ $ nstat | grep -e Udp -e Ip
> > IpInReceives 24 0.0
> > IpInDelivers 24 0.0
> > IpOutRequests 18 0.0
> > UdpInErrors 22 0.0
> > UdpOutDatagrams 16 0.0
> > Ip6InReceives 15 0.0
> > Ip6InDelivers 12 0.0
> > Ip6OutRequests 10 0.0
> > Ip6InMcastPkts 3 0.0
> > Ip6InOctets 1160 0.0
> > Ip6OutOctets 2456 0.0
> > Ip6InMcastOctets 216 0.0
> > Ip6InNoECTPkts 15 0.0
> > IpExtInOctets 8612 0.0
> > IpExtOutOctets 1127 0.0
> > IpExtInNoECTPkts 24 0.0
> > [17/1077]mh@impetus:~ $ nstat | grep -e Udp -e Ip
> > IpInReceives 5 0.0
> > IpInDelivers 4 0.0
> > IpOutRequests 3 0.0
> > UdpNoPorts 1 0.0
> > UdpInErrors 2 0.0
> > UdpOutDatagrams 1 0.0
> > Ip6InReceives 12 0.0
> > Ip6InDelivers 12 0.0
> > Ip6OutRequests 10 0.0
> > Ip6InOctets 944 0.0
> > Ip6OutOctets 2364 0.0
> > Ip6InNoECTPkts 12 0.0
> > IpExtInOctets 429 0.0
> > IpExtOutOctets 226 0.0
> > IpExtInNoECTPkts 5 0.0
> > [18/1077]mh@impetus:~ $
> >
> > And here, hopefully a bit more helpful:
> >
> > [19/1078]mh@impetus:~ $ ss -u ; nstat | grep -e Udp -e Ip ; dig +time=2 @8.8.8.8 zugschlus.de mx ; ss -u ; nstat | grep -e Udp -e Ip
> > Recv-Q Send-Q Local Address:Port Peer Address:Port
> > 0 0 216.231.132.60:27333 198.41.0.4:domain
> > 0 0 216.231.132.60:38101 198.41.0.4:domain
> > 0 0 216.231.132.60:15836 198.41.0.4:domain
> > 0 0 216.231.132.60:50655 8.8.8.8:domain
> > 0 0 216.231.132.60:41953 198.41.0.4:domain
> > 0 0 216.231.132.60:6888 198.41.0.4:domain
> > 0 0 216.231.132.60:51441 198.41.0.4:domain
> > 0 0 216.231.132.60:42503 198.41.0.4:domain
> > 0 0 216.231.132.60:12575 198.41.0.4:domain
> > 0 0 216.231.132.60:13857 198.41.0.4:domain
> > 0 0 216.231.132.60:16419 192.36.148.17:domain
> > 0 0 216.231.132.60:39227 198.41.0.4:domain
> > 0 0 127.0.0.1:54608 127.0.0.1:domain
> > 0 0 216.231.132.60:20818 198.41.0.4:domain
> > 0 0 216.231.132.60:56662 198.41.0.4:domain
> > 0 0 216.231.132.60:48259 192.36.148.17:domain
> > 0 0 216.231.132.60:37803 198.41.0.4:domain
> > IpInReceives 59 0.0
> > IpInAddrErrors 1 0.0
> > IpInDelivers 56 0.0
> > IpOutRequests 50 0.0
> > UdpInDatagrams 1 0.0
> > UdpInErrors 50 0.0
> > UdpOutDatagrams 47 0.0
> > UdpIgnoredMulti 1 0.0
> > Ip6InReceives 75 0.0
> > Ip6InDelivers 73 0.0
> > Ip6OutRequests 64 0.0
> > Ip6InMcastPkts 2 0.0
> > Ip6InOctets 7837 0.0
> > Ip6OutOctets 11876 0.0
> > Ip6InMcastOctets 279 0.0
> > Ip6InNoECTPkts 75 0.0
> > Udp6InErrors 3 0.0
> > IpExtInBcastPkts 1 0.0
> > IpExtInOctets 18447 0.0
> > IpExtOutOctets 3478 0.0
> > IpExtInBcastOctets 183 0.0
> > IpExtInNoECTPkts 59 0.0
> >
> > ; <<>> DiG 9.10.3-P4-Debian <<>> +time=2 @8.8.8.8 zugschlus.de mx
> > ; (1 server found)
> > ;; global options: +cmd
> > ;; connection timed out; no servers could be reached
> > Recv-Q Send-Q Local Address:Port Peer Address:Port
> > 0 0 216.231.132.60:7879 202.12.27.33:domain
> > 0 0 216.231.132.60:32711 202.12.27.33:domain
> > 0 0 216.231.132.60:54238 202.12.27.33:domain
> > 0 0 216.231.132.60:30948 192.228.79.201:domain
> > 0 0 216.231.132.60:4106 202.12.27.33:domain
> > 0 0 216.231.132.60:6667 202.12.27.33:domain
> > 0 0 216.231.132.60:2090 192.228.79.201:domain
> > 0 0 216.231.132.60:60459 192.228.79.201:domain
> > 0 0 216.231.132.60:16427 202.12.27.33:domain
> > 0 0 216.231.132.60:9019 202.12.27.33:domain
> > 0 0 216.231.132.60:2113 202.12.27.33:domain
> > 0 0 216.231.132.60:34907 202.12.27.33:domain
> > 0 0 216.231.132.60:34654 202.12.27.33:domain
> > 0 0 216.231.132.60:47725 202.12.27.33:domain
> > 0 0 216.231.132.60:35774 202.12.27.33:domain
> > IpInReceives 38 0.0
> > IpInDelivers 38 0.0
> > IpOutRequests 38 0.0
> > UdpInDatagrams 2 0.0
> > UdpInErrors 34 0.0
> > UdpOutDatagrams 36 0.0
> > Ip6InReceives 14 0.0
> > Ip6InDelivers 13 0.0
> > Ip6OutRequests 13 0.0
> > Ip6InMcastPkts 1 0.0
> > Ip6InOctets 1046 0.0
> > Ip6OutOctets 6277 0.0
> > Ip6InMcastOctets 133 0.0
> > Ip6InNoECTPkts 13 0.0
> > Ip6InECT0Pkts 1 0.0
> > Udp6InDatagrams 1 0.0
> > Udp6OutDatagrams 1 0.0
> > IpExtInOctets 15963 0.0
> > IpExtOutOctets 2397 0.0
> > IpExtInNoECTPkts 37 0.0
> > IpExtInECT0Pkts 1 0.0
> > [20/1079]mh@impetus:~ $
> >
> > I am afraid I cannot keep this state for much longer than a few
> > additional hours as this is an authoritative name server...
> >
> > Greetings
> > Marc
> >
>
> To confirm the refcount issue, you might send us :
>
> cat /proc/net/udp6
>
> Normally, the refcount column should have a value of 2
I think that the leaked sockets are still unhashed on close() (via
udp_lib_close() -> sk_common_release() ->sk_proto->unhash()), so they
should not be listed there ?!? (Rush answer, subject to lack of coffee
issues)
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH v2 01/11] net: phy: Add rockchip phy driver support
From: David.Wu @ 2017-07-28 8:19 UTC (permalink / raw)
To: Florian Fainelli, davem, heiko, andrew, robh+dt, mark.rutland,
catalin.marinas, will.deacon, olof, linux, arnd
Cc: peppe.cavallaro, alexandre.torgue, huangtao, hwg, netdev,
linux-arm-kernel, linux-rockchip, devicetree, linux-kernel
In-Reply-To: <807c43ee-8421-c0b3-8aea-6091bef07a4c@gmail.com>
Hi Florian,
在 2017/7/28 0:51, Florian Fainelli 写道:
>> +}
>> +
>> +static int rockchip_internal_phy_config_init(struct phy_device *phydev)
>> +{
>> + int val;
>> +
>> + /*
>> + * The auto MIDX has linked problem on some board,
>> + * workround to disable auto MDIX.
>> + */
> If this a board-specific problem you may consider register a PHY fixup
> for the affected boards, or introduce a specific property to illustrate
> that MDI-X is broken.
You mean is that if I need disable Auto-mdix, then I'm going to add a
property to DTS, from here to decide whether or not to close Auto-mdix?
>
^ permalink raw reply
* Re: After a while of system running no incoming UDP any more?
From: Eric Dumazet @ 2017-07-28 8:41 UTC (permalink / raw)
To: Paolo Abeni; +Cc: Marc Haber, netdev
In-Reply-To: <1501229702.2597.3.camel@redhat.com>
On Fri, 2017-07-28 at 10:15 +0200, Paolo Abeni wrote:
> Hi,
>
> On Fri, 2017-07-28 at 01:05 -0700, Eric Dumazet wrote:
> I think that the leaked sockets are still unhashed on close() (via
> udp_lib_close() -> sk_common_release() ->sk_proto->unhash()), so they
> should not be listed there ?!? (Rush answer, subject to lack of coffee
> issues)
If the daemon is still running, sockets are not closed and we can watch
refcount being increased.
We can see this even on an UDP_RR workload (no UDP flood at all)
lpk51:~# while :
> do
> ./super_netperf 10 -H 2002:af6:b34:: -t UDP_RR -l 1 -- -N
> done
lpk52:~# cat /proc/net/udp6|grep -v " 2 "
sl local_address remote_address
st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref
pointer drops
293: F60A02200000340B0000000000000000:F0A9
F60A02200000330B0000000000000000:AB11 01 00000000:00000000 00:00000000
00000000 0 0 583763 387 ffff880ddb862c00 0
3251: F60A02200000340B0000000000000000:FC37
F60A02200000330B0000000000000000:EA7F 01 00000000:00000000 00:00000000
00000000 0 0 586126 356 ffff880dd25a7940 0
4043: F60A02200000340B0000000000000000:FF4F
F60A02200000330B0000000000000000:9A35 01 00000500:00000000 00:00000000
00000000 0 0 583760 409 ffff880ddb863180 0
7832: F60A02200000340B0000000000000000:8E1C
F60A02200000330B0000000000000000:DEC1 01 00000000:00000000 00:00000000
00000000 0 0 583766 387 ffff880ddb863700 0
8568: F60A02200000340B0000000000000000:90FC
F60A02200000330B0000000000000000:8A60 01 00000000:00000000 00:00000000
00000000 0 0 580369 379 ffff880d9e7b2700 0
13085: F60A02200000340B0000000000000000:A2A1
F60A02200000330B0000000000000000:CDB3 01 00000000:00000000 00:00000000
00000000 0 0 586915 397 ffff880e31994140 0
14975: F60A02200000340B0000000000000000:AA03
F60A02200000330B0000000000000000:9C71 01 00000000:00000000 00:00000000
00000000 0 0 586123 355 ffff880d9d1baec0 0
15155: F60A02200000340B0000000000000000:AAB7
F60A02200000330B0000000000000000:D324 01 00000000:00000000 00:00000000
00000000 0 0 583769 367 ffff880dd88141c0 0
25421: F60A02200000340B0000000000000000:D2D1
F60A02200000330B0000000000000000:CA33 01 00000000:00000000 00:00000000
00000000 0 0 586120 424 ffff880dfda4b0c0 0
28774: F60A02200000340B0000000000000000:DFEA
F60A02200000330B0000000000000000:DD05 01 00000500:00000000 00:00000000
00000000 0 0 583757 411 ffff880ddb862680 0
^ permalink raw reply
* Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings
From: Oliver Hartkopp @ 2017-07-28 8:41 UTC (permalink / raw)
To: Franklin S Cooper Jr, Andrew Lunn, linux-kernel, devicetree,
netdev, linux-can, wg, mkl, robh+dt, quentin.schulz,
sergei.shtylyov
In-Reply-To: <20170728045724.GA27903@airbook.vandijck-laurijssen.be>
On 07/28/2017 06:57 AM, Kurt Van Dijck wrote:
> So while _a_ transceiver may be spec'd to 1MBit during arbitration,
> CAN FD packets may IMHO exceed that speed during data phase.
When the bitrate is limited to 1Mbit/s you are ONLY allowed to use
1Mbit/s in the data section too (either with CAN or CAN FD).
> That was the whole point of CAN FD: exceed the limits required for
> correct arbitration on transceiver & wire.
No. CAN FD is about a different frame format with up to 64 bytes AND the
possibility to increase the bitrate in the data section of the frame.
> So I do not agree on the single bandwidth limitation.
The transceiver provides a single maximum bandwidth. It's an ISO Layer 1
device.
> The word 'max-arbitration-bitrate' makes the difference very clear.
I think you are mixing up ISO layer 1 and ISO layer 2.
Regards,
Oliver
^ permalink raw reply
* [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode
From: Corentin Labbe @ 2017-07-28 9:28 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: icenowy-h8G6r0blFSE, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
Hello
The current way to find if the phy is internal is to compare DT phy-mode
and emac_variant/internal_phy.
But it will negate a possible future SoC where an external PHY use the
same phy mode than the internal one.
This patchs series adds a new way to find if the PHY is internal, via its
compatible.
Corentin Labbe (3):
dt-bindings: net: add compatible for internal sun8i-h3/sun8i-v3s PHYs
ARM: sunxi: h3/h5: Add sun8i-h3-ephy compatible
net-next: stmmac: dwmac-sun8i: choose internal PHY via compatible
Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 4 ++--
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 3 ++-
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 16 ++++++++++------
3 files changed, 14 insertions(+), 9 deletions(-)
--
2.13.0
^ permalink raw reply
* [PATCH 1/3] dt-bindings: net: add compatible for internal sun8i-h3/sun8i-v3s PHYs
From: Corentin Labbe @ 2017-07-28 9:28 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: icenowy-h8G6r0blFSE, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
In-Reply-To: <20170728092818.23419-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The internal PHYs for H3 ans V3S now need to have their own compatible.
This patch rename them in the binding documentation.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 725f3b187886..851e89052424 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -49,8 +49,8 @@ The device node referenced by "phy" or "phy-handle" should be a child node
of the mdio node. See phy.txt for the generic PHY bindings.
Required properties of the phy node with the following compatibles:
- - "allwinner,sun8i-h3-emac",
- - "allwinner,sun8i-v3s-emac":
+ - "allwinner,sun8i-h3-ephy",
+ - "allwinner,sun8i-v3s-ephy":
- clocks: a phandle to the reference clock for the EPHY
- resets: a phandle to the reset control for the EPHY
--
2.13.0
^ permalink raw reply related
* [PATCH 2/3] ARM: sunxi: h3/h5: Add sun8i-h3-ephy compatible
From: Corentin Labbe @ 2017-07-28 9:28 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: icenowy-h8G6r0blFSE, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
In-Reply-To: <20170728092818.23419-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch adds the sun8i-h3-ephy compatible to the internal PHY.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 4b599b5d26f6..7aaa837c2388 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -421,7 +421,8 @@
#address-cells = <1>;
#size-cells = <0>;
int_mii_phy: ethernet-phy@1 {
- compatible = "ethernet-phy-ieee802.3-c22";
+ compatible = "allwinner,sun8i-h3-ephy",
+ "ethernet-phy-ieee802.3-c22";
reg = <1>;
clocks = <&ccu CLK_BUS_EPHY>;
resets = <&ccu RST_BUS_EPHY>;
--
2.13.0
^ permalink raw reply related
* [PATCH 3/3] net-next: stmmac: dwmac-sun8i: choose internal PHY via compatible
From: Corentin Labbe @ 2017-07-28 9:28 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: icenowy-h8G6r0blFSE, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
In-Reply-To: <20170728092818.23419-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The current way to find if the phy is internal is to compare DT phy-mode
and emac_variant/internal_phy.
But it will negate a possible future SoC where an external PHY use the
same phy mode than the internal one.
This patch adds a new way to find if the PHY is internal, via its
compatible.
Since the phy_mode of the internal PHY does need to be know, the
variant internal_phy member is converted to a boolean.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index fffd6d5fc907..04f7ddd802b0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -48,7 +48,7 @@
*/
struct emac_variant {
u32 default_syscon_value;
- int internal_phy;
+ bool internal_phy;
bool support_mii;
bool support_rmii;
bool support_rgmii;
@@ -75,7 +75,7 @@ struct sunxi_priv_data {
static const struct emac_variant emac_variant_h3 = {
.default_syscon_value = 0x58000,
- .internal_phy = PHY_INTERFACE_MODE_MII,
+ .internal_phy = true,
.support_mii = true,
.support_rmii = true,
.support_rgmii = true
@@ -83,20 +83,20 @@ static const struct emac_variant emac_variant_h3 = {
static const struct emac_variant emac_variant_v3s = {
.default_syscon_value = 0x38000,
- .internal_phy = PHY_INTERFACE_MODE_MII,
+ .internal_phy = true,
.support_mii = true
};
static const struct emac_variant emac_variant_a83t = {
.default_syscon_value = 0,
- .internal_phy = 0,
+ .internal_phy = false,
.support_mii = true,
.support_rgmii = true
};
static const struct emac_variant emac_variant_a64 = {
.default_syscon_value = 0,
- .internal_phy = 0,
+ .internal_phy = false,
.support_mii = true,
.support_rmii = true,
.support_rgmii = true
@@ -889,6 +889,10 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
struct sunxi_priv_data *gmac;
struct device *dev = &pdev->dev;
int ret;
+ static const struct of_device_id internal_phys[] = {
+ { .compatible = "allwinner,sun8i-h3-ephy" },
+ { .compatible = "allwinner,sun8i-v3s-ephy" },
+ };
ret = stmmac_get_platform_resources(pdev, &stmmac_res);
if (ret)
@@ -932,7 +936,7 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
}
plat_dat->interface = of_get_phy_mode(dev->of_node);
- if (plat_dat->interface == gmac->variant->internal_phy) {
+ if (of_match_node(internal_phys, plat_dat->phy_node)) {
dev_info(&pdev->dev, "Will use internal PHY\n");
gmac->use_internal_phy = true;
gmac->ephy_clk = of_clk_get(plat_dat->phy_node, 0);
--
2.13.0
^ 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