* linux-next: Signed-off-by missing for commit in the net tree
From: Stephen Rothwell @ 2018-11-21 5:04 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 186 bytes --]
Hi all,
Commit
f2cbd4852820 ("net/sched: act_police: fix race condition on state variables")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v1 net] lan743x: fix return value for lan743x_tx_napi_poll
From: Bryan Whitehead @ 2018-11-20 18:26 UTC (permalink / raw)
To: davem; +Cc: netdev, UNGLinuxDriver
It has been noticed that under stress the lan743x driver will
sometimes hang or cause a kernel panic. It has been noticed
that returning '0' instead of 'weight' fixes this issue.
fixes: rare kernel panic under heavy traffic load.
Signed-off-by: Bryan Whitehead <Bryan.Whitehead@microchip.com>
---
drivers/net/ethernet/microchip/lan743x_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
index 867cddb..ca33ade 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -1672,7 +1672,7 @@ static int lan743x_tx_napi_poll(struct napi_struct *napi, int weight)
netif_wake_queue(adapter->netdev);
}
- if (!napi_complete_done(napi, weight))
+ if (!napi_complete_done(napi, 0))
goto done;
/* enable isr */
@@ -1681,7 +1681,7 @@ static int lan743x_tx_napi_poll(struct napi_struct *napi, int weight)
lan743x_csr_read(adapter, INT_STS);
done:
- return weight;
+ return 0;
}
static void lan743x_tx_ring_cleanup(struct lan743x_tx *tx)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next] mlxsw: core: Extend cooling device with cooling levels
From: David Miller @ 2018-11-20 18:31 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, vadimp, alexpe, mlxsw
In-Reply-To: <20181120065121.542-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Tue, 20 Nov 2018 06:52:03 +0000
> From: Vadim Pasternak <vadimp@mellanox.com>
>
> Extend cooling device with cooling levels vector to allow more
> flexibility of PWM setting.
>
> Thermal zone algorithm operates with the numerical states for PWM
> setting. Each state is the index, defined in range from 0 to 10 and it's
> mapped to the relevant duty cycle value, which is written to PWM
> controller. With the current definition fan speed is set to 0% for state
> 0, 10% for state 1, and so on up to 100% for the maximum state 10.
>
> Some systems have limitation for the PWM speed minimum. For such systems
> PWM setting speed to 0% will just disable the ability to increase speed
> anymore and such device will be stall on zero speed. Cooling levels
> allow to configure state vector according to the particular system
> requirements. For example, if PWM speed is not allowed to be below 30%,
> cooling levels could be configured as 30%, 30%, 30%, 30%, 40%, 50% and
> so on.
>
> Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next] cxgb4/cxgb4vf: Fix mac_hlist initialization and free
From: David Miller @ 2018-11-20 18:29 UTC (permalink / raw)
To: arjun; +Cc: netdev, nirranjan, indranil, dt, leon, leedom, ganeshgr
In-Reply-To: <20181120064139.19063-1-arjun@chelsio.com>
From: Arjun Vynipadath <arjun@chelsio.com>
Date: Tue, 20 Nov 2018 12:11:39 +0530
> Null pointer dereference seen when cxgb4vf driver is unloaded
> without bringing up any interfaces, moving mac_hlist initialization
> to driver probe and free the mac_hlist in remove to fix the issue.
>
> Fixes: 24357e06ba51 ("cxgb4vf: fix memleak in mac_hlist initialization")
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> ---
> v2:
> - Updated commit description as per Leon's feedback
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tcp: drop dst in tcp_add_backlog()
From: David Miller @ 2018-11-20 18:26 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <CANn89i+ZMuSm9mEy101wuxWBgnd64nXh7fgoYq-TTTU7RwPPSQ@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
Date: Tue, 20 Nov 2018 10:21:22 -0800
> On Tue, Nov 20, 2018 at 10:16 AM David Miller <davem@davemloft.net> wrote:
>>
>> Well, I'm sure we "handle" it. But I was more asking about the performance
>> tradeoff, which probably is on the side of your change but I wanted to
>> just be sure.
>
> Ah sorry for misunderstanding.
> Yes, that should be fine, backlog is not generally used at the
> beginning of a flow.
>
> I am working on adding coalescing support to tcp_add_backlog() to balance
> time spent in softirq and time spent from process context, hoping to reduce
> probability of having user threads trapped for a while in __release_sock()
Ok, meanwhile I applied the patch under discussion.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] tcp: drop dst in tcp_add_backlog()
From: Eric Dumazet @ 2018-11-20 18:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <20181120.101638.365512079157603391.davem@davemloft.net>
On Tue, Nov 20, 2018 at 10:16 AM David Miller <davem@davemloft.net> wrote:
>
> From: Eric Dumazet <edumazet@google.com>
> Date: Tue, 20 Nov 2018 10:08:12 -0800
>
> > On Tue, Nov 20, 2018 at 10:01 AM David Miller <davem@davemloft.net> wrote:
> >>
> >> From: Eric Dumazet <edumazet@google.com>
> >> Date: Mon, 19 Nov 2018 17:45:55 -0800
> >>
> >> > Under stress, softirq rx handler often hits a socket owned by the user,
> >> > and has to queue the packet into socket backlog.
> >> >
> >> > When this happens, skb dst refcount is taken before we escape rcu
> >> > protected region. This is done from __sk_add_backlog() calling
> >> > skb_dst_force().
> >> >
> >> > Consumer will have to perform the opposite costly operation.
> >> >
> >> > AFAIK nothing in tcp stack requests the dst after skb was stored
> >> > in the backlog. If this was the case, we would have had failures
> >> > already since skb_dst_force() can end up clearing skb dst anyway.
> >> >
> >> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> >>
> >> Hmmm, it seems to be used by connection completion code to setup the
> >> socket cached rx dst, right?
> >>
> >> For example tcp_finish_connect() --> icsk->icsk_af_ops->sk_rx_dst_set(sk, skb)
> >
> > We already cope with skb->dst being NULL there I believe.
> >
> > For reference look at
> >
> > commit 5037e9ef9454917b047f9f3a19b4dd179fbf7cd4 net: fix IP early demux races
>
> Well, I'm sure we "handle" it. But I was more asking about the performance
> tradeoff, which probably is on the side of your change but I wanted to
> just be sure.
Ah sorry for misunderstanding.
Yes, that should be fine, backlog is not generally used at the
beginning of a flow.
I am working on adding coalescing support to tcp_add_backlog() to balance
time spent in softirq and time spent from process context, hoping to reduce
probability of having user threads trapped for a while in __release_sock()
^ permalink raw reply
* Re: [RFC v3 3/3] vxlan: handle underlay VRF changes
From: Alexis Bauvin @ 2018-11-20 18:19 UTC (permalink / raw)
To: David Ahern, Roopa Prabhu; +Cc: netdev, akherbouche
In-Reply-To: <2c97f9b6-ce98-671b-ce78-e55a3ef10159@cumulusnetworks.com>
Le 20 nov. 2018 à 17:13, David Ahern <dsa@cumulusnetworks.com> a écrit :
> On 11/20/18 8:48 AM, David Ahern wrote:
>> On 11/20/18 8:35 AM, Roopa Prabhu wrote:
>>> On Tue, Nov 20, 2018 at 7:04 AM David Ahern <dsa@cumulusnetworks.com> wrote:
>>>>
>>>> On 11/20/18 7:23 AM, Alexis Bauvin wrote:
>>>>> When underlay VRF changes, either because the lower device itself changed,
>>>>> or its VRF changed, this patch releases the current socket of the VXLAN
>>>>> device and recreates another one in the right VRF. This allows for
>>>>> on-the-fly change of the underlay VRF of a VXLAN device.
>>>>>
>>>>> Signed-off-by: Alexis Bauvin <abauvin@scaleway.com>
>>>>> Reviewed-by: Amine Kherbouche <akherbouche@scaleway.com>
>>>>> Tested-by: Amine Kherbouche <akherbouche@scaleway.com>
>>>>> ---
>>>>> drivers/net/vxlan.c | 94 +++++++++++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 94 insertions(+)
>>>>>
>>>>> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
>>>>> index a3de08122269..1e6ccad6df6a 100644
>>>>> --- a/drivers/net/vxlan.c
>>>>> +++ b/drivers/net/vxlan.c
>>>>> @@ -208,6 +208,18 @@ static inline struct vxlan_rdst *first_remote_rtnl(struct vxlan_fdb *fdb)
>>>>> return list_first_entry(&fdb->remotes, struct vxlan_rdst, list);
>>>>> }
>>>>>
>>>>> +static int vxlan_is_in_l3mdev_chain(struct net_device *chain,
>>>>> + struct net_device *dev)
>>>>> +{
>>>>> + if (!chain)
>>>>> + return 0;
>>>>> +
>>>>> + if (chain->ifindex == dev->ifindex)
>>>>> + return 1;
>>>>> + return vxlan_is_in_l3mdev_chain(netdev_master_upper_dev_get(chain),
>>>>> + dev);
>>>>> +}
>>>>
>>>> This should return bool and true/false.
>>>>
>>>> Also, why l3mdev in the name? None of the checks look at whether it is
>>>> an l3mdev master.
>>>>
>>>> And again here, someone more familiar with the vxlan code should review it.
>>>>
>>>
>>>
>>> I understand the need for patch 2. But I don't understand the need for
>>> the complexity this patch introduces (especially implicit down and up
>>> of the vxlan device).
>>> Alexis, If your underlay routing changes, you can down and up the
>>> vxlan device from user-space correct ?. This should be true for any
>>> tunnel device.
>>>
>>
>> I believe this patch handles changes to the VRF association of the bridge.
>>
> Re-reading the commit message, this handles changes in VRF association
> of the lower device.
Yes
> If the vxlan socket in general (vrf or not) can be bound to the lower
> device instead of the VRF then it simplifies things a lot.
It would indeed make things simpler, as this patch would mostly be useless.
There is no technical reason not to have done so, except for the conceptual
idea that you bind to the vrf device to add vrf-awareness.
It only removes part of the complexity, as handling a change of lower device
itself would still be needed (ip link set vxlan-blue type vxlan dev eth1)
to rebind the socket.
I will try to bind the sockets to the lower device to see if there are any
shortcomings to this method.
^ permalink raw reply
* Re: [PATCH net] tg3: Add PHY reset for 5717/5719/5720 in change ring and flow control paths
From: David Miller @ 2018-11-20 18:18 UTC (permalink / raw)
To: siva.kallam; +Cc: netdev, michael.chan, prashant, siva.kallam
In-Reply-To: <20181120043404.66934-1-siva.kallam@broadom.com>
From: Siva Reddy Kallam <siva.kallam@broadom.com>
Date: Tue, 20 Nov 2018 10:04:04 +0530
> From: Siva Reddy Kallam <siva.kallam@broadcom.com>
>
> This patch has the fix to avoid PHY lockup with 5717/5719/5720 in change
> ring and flow control paths. This patch solves the RX hang while doing
> continuous ring or flow control parameters with heavy traffic from peer.
>
> Signed-off-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
> Acked-by: Michael Chan <michael.chan@broadcom.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [Patch net] net: invert the check of detecting hardware RX checksum fault
From: Eric Dumazet @ 2018-11-20 18:18 UTC (permalink / raw)
To: David Miller
Cc: Eric Dumazet, Cong Wang, Herbert Xu, netdev, Tom Herbert,
Saeed Mahameed
In-Reply-To: <20181120.101340.1401026987466664720.davem@davemloft.net>
On Tue, Nov 20, 2018 at 10:13 AM David Miller <davem@davemloft.net> wrote:
>
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 19 Nov 2018 17:47:33 -0800
>
> >
> >
> > On 11/19/2018 05:42 PM, Cong Wang wrote:
> >> On Fri, Nov 16, 2018 at 12:15 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> >>>
> >>> On Thu, Nov 15, 2018 at 8:52 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >>>>
> >>>> You could use trafgen to cook such a frame and confirm the theory.
> >>>>
> >>>> Something like :
> >>>
> >>> I will try it.
> >>
> >> I just tried it, it doesn't make much difference, the warning only
> >> shows up once after I ran the trafgen script for many times,
> >> it could be triggered by other daemons running on the host too.
> >
> >
> > I guess we will need to dump the whole packet for debugging,
> > as suggest by Herbert :/
>
> Something like this? Is it safe to linearize here?
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index f2bfd2eda7b2..3955939cc0cf 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3094,6 +3094,8 @@ EXPORT_SYMBOL(__skb_gso_segment);
> void netdev_rx_csum_fault(struct net_device *dev, struct sk_buff *skb)
> {
> if (net_ratelimit()) {
> + static unsigned long last_full_pkt_dump = ~0UL;
> +
> pr_err("%s: hw csum failure\n", dev ? dev->name : "<unknown>");
> if (dev)
> pr_err("dev features: %pNF\n", &dev->features);
> @@ -3102,6 +3104,13 @@ void netdev_rx_csum_fault(struct net_device *dev, struct sk_buff *skb)
> skb_shinfo(skb)->gso_size, skb_shinfo(skb)->gso_type,
> skb_shinfo(skb)->nr_frags, skb->ip_summed, skb->csum,
> skb->csum_complete_sw, skb->csum_valid, skb->csum_level);
> + if (jiffies - last_full_pkt_dump >= (HZ * 60 * 5) &&
> + !skb_linearize(skb)) {
> + last_full_pkt_dump = jiffies;
> + print_hex_dump(KERN_ERR, "skb data: ",
> + DUMP_PREFIX_OFFSET, 32, 1,
> + skb->data, skb->len, false);
I guess we should dump from skb->head instead, to show all headers.
Maybe dump the mac header offset as well, so that we can ignore the
padding bytes (NET_SKB_PAD) if needed.
^ permalink raw reply
* Re: [PATCH net-next] tcp: drop dst in tcp_add_backlog()
From: David Miller @ 2018-11-20 18:16 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <CANn89iKubtjj-a8TNYHyVU=Xv24eqriQkV=sE6TCgqbjYYVr_w@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
Date: Tue, 20 Nov 2018 10:08:12 -0800
> On Tue, Nov 20, 2018 at 10:01 AM David Miller <davem@davemloft.net> wrote:
>>
>> From: Eric Dumazet <edumazet@google.com>
>> Date: Mon, 19 Nov 2018 17:45:55 -0800
>>
>> > Under stress, softirq rx handler often hits a socket owned by the user,
>> > and has to queue the packet into socket backlog.
>> >
>> > When this happens, skb dst refcount is taken before we escape rcu
>> > protected region. This is done from __sk_add_backlog() calling
>> > skb_dst_force().
>> >
>> > Consumer will have to perform the opposite costly operation.
>> >
>> > AFAIK nothing in tcp stack requests the dst after skb was stored
>> > in the backlog. If this was the case, we would have had failures
>> > already since skb_dst_force() can end up clearing skb dst anyway.
>> >
>> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>>
>> Hmmm, it seems to be used by connection completion code to setup the
>> socket cached rx dst, right?
>>
>> For example tcp_finish_connect() --> icsk->icsk_af_ops->sk_rx_dst_set(sk, skb)
>
> We already cope with skb->dst being NULL there I believe.
>
> For reference look at
>
> commit 5037e9ef9454917b047f9f3a19b4dd179fbf7cd4 net: fix IP early demux races
Well, I'm sure we "handle" it. But I was more asking about the performance
tradeoff, which probably is on the side of your change but I wanted to
just be sure.
^ permalink raw reply
* [PATCH] ipv4: Don't try to print ASCII of link level header in martian dumps.
From: David Miller @ 2018-11-20 18:16 UTC (permalink / raw)
To: netdev
This has no value whatsoever.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index c0a9d26c06ce..c4ddbc5f01fc 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1677,7 +1677,7 @@ static void ip_handle_martian_source(struct net_device *dev,
print_hex_dump(KERN_WARNING, "ll header: ",
DUMP_PREFIX_OFFSET, 16, 1,
skb_mac_header(skb),
- dev->hard_header_len, true);
+ dev->hard_header_len, false);
}
}
#endif
--
2.19.1
^ permalink raw reply related
* [PATCH net-next v2 2/4] enetc: Add ethtool statistics
From: Claudiu Manoil @ 2018-11-20 18:15 UTC (permalink / raw)
To: David S . Miller, netdev
Cc: linux-kernel, alexandru.marginean, catalin.horghidan
In-Reply-To: <1542737734-21756-1-git-send-email-claudiu.manoil@nxp.com>
This adds most h/w statistics counters: non-privileged SI conters, as
well as privileged Port and MAC counters available only to the PF.
Per ring software stats are also included.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v2: - replaced sprintf by snprintf
.../net/ethernet/freescale/enetc/enetc_ethtool.c | 187 +++++++++++++++++++++
drivers/net/ethernet/freescale/enetc/enetc_hw.h | 88 ++++++++++
2 files changed, 275 insertions(+)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
index 365ac9c..9032b0e 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
@@ -89,6 +89,187 @@ static void enetc_get_regs(struct net_device *ndev, struct ethtool_regs *regs,
}
}
+static const struct {
+ int reg;
+ char name[ETH_GSTRING_LEN];
+} enetc_si_counters[] = {
+ { ENETC_SIROCT, "SI rx octets" },
+ { ENETC_SIRFRM, "SI rx frames" },
+ { ENETC_SIRUCA, "SI rx u-cast frames" },
+ { ENETC_SIRMCA, "SI rx m-cast frames" },
+ { ENETC_SITOCT, "SI tx octets" },
+ { ENETC_SITFRM, "SI tx frames" },
+ { ENETC_SITUCA, "SI tx u-cast frames" },
+ { ENETC_SITMCA, "SI tx m-cast frames" },
+ { ENETC_RBDCR(0), "Rx ring 0 discarded frames" },
+ { ENETC_RBDCR(1), "Rx ring 1 discarded frames" },
+ { ENETC_RBDCR(2), "Rx ring 2 discarded frames" },
+ { ENETC_RBDCR(3), "Rx ring 3 discarded frames" },
+ { ENETC_RBDCR(4), "Rx ring 4 discarded frames" },
+ { ENETC_RBDCR(5), "Rx ring 5 discarded frames" },
+ { ENETC_RBDCR(6), "Rx ring 6 discarded frames" },
+ { ENETC_RBDCR(7), "Rx ring 7 discarded frames" },
+ { ENETC_RBDCR(8), "Rx ring 8 discarded frames" },
+ { ENETC_RBDCR(9), "Rx ring 9 discarded frames" },
+ { ENETC_RBDCR(10), "Rx ring 10 discarded frames" },
+ { ENETC_RBDCR(11), "Rx ring 11 discarded frames" },
+ { ENETC_RBDCR(12), "Rx ring 12 discarded frames" },
+ { ENETC_RBDCR(13), "Rx ring 13 discarded frames" },
+ { ENETC_RBDCR(14), "Rx ring 14 discarded frames" },
+ { ENETC_RBDCR(15), "Rx ring 15 discarded frames" },
+};
+
+static const struct {
+ int reg;
+ char name[ETH_GSTRING_LEN];
+} enetc_port_counters[] = {
+ { ENETC_PM0_REOCT, "MAC rx ethernet octets" },
+ { ENETC_PM0_RALN, "MAC rx alignment errors" },
+ { ENETC_PM0_RXPF, "MAC rx valid pause frames" },
+ { ENETC_PM0_RFRM, "MAC rx valid frames" },
+ { ENETC_PM0_RFCS, "MAC rx fcs errors" },
+ { ENETC_PM0_RVLAN, "MAC rx VLAN frames" },
+ { ENETC_PM0_RERR, "MAC rx frame errors" },
+ { ENETC_PM0_RUCA, "MAC rx unicast frames" },
+ { ENETC_PM0_RMCA, "MAC rx multicast frames" },
+ { ENETC_PM0_RBCA, "MAC rx broadcast frames" },
+ { ENETC_PM0_RDRP, "MAC rx dropped packets" },
+ { ENETC_PM0_RPKT, "MAC rx packets" },
+ { ENETC_PM0_RUND, "MAC rx undersized packets" },
+ { ENETC_PM0_R64, "MAC rx 64 byte packets" },
+ { ENETC_PM0_R127, "MAC rx 65-127 byte packets" },
+ { ENETC_PM0_R255, "MAC rx 128-255 byte packets" },
+ { ENETC_PM0_R511, "MAC rx 256-511 byte packets" },
+ { ENETC_PM0_R1023, "MAC rx 512-1023 byte packets" },
+ { ENETC_PM0_R1518, "MAC rx 1024-1518 byte packets" },
+ { ENETC_PM0_R1519X, "MAC rx 1519 to max-octet packets" },
+ { ENETC_PM0_ROVR, "MAC rx oversized packets" },
+ { ENETC_PM0_RJBR, "MAC rx jabber packets" },
+ { ENETC_PM0_RFRG, "MAC rx fragment packets" },
+ { ENETC_PM0_RCNP, "MAC rx control packets" },
+ { ENETC_PM0_RDRNTP, "MAC rx fifo drop" },
+ { ENETC_PM0_TEOCT, "MAC tx ethernet octets" },
+ { ENETC_PM0_TOCT, "MAC tx octets" },
+ { ENETC_PM0_TCRSE, "MAC tx carrier sense errors" },
+ { ENETC_PM0_TXPF, "MAC tx valid pause frames" },
+ { ENETC_PM0_TFRM, "MAC tx frames" },
+ { ENETC_PM0_TFCS, "MAC tx fcs errors" },
+ { ENETC_PM0_TVLAN, "MAC tx VLAN frames" },
+ { ENETC_PM0_TERR, "MAC tx frames" },
+ { ENETC_PM0_TUCA, "MAC tx unicast frames" },
+ { ENETC_PM0_TMCA, "MAC tx multicast frames" },
+ { ENETC_PM0_TBCA, "MAC tx broadcast frames" },
+ { ENETC_PM0_TPKT, "MAC tx packets" },
+ { ENETC_PM0_TUND, "MAC tx undersized packets" },
+ { ENETC_PM0_T127, "MAC tx 65-127 byte packets" },
+ { ENETC_PM0_T1023, "MAC tx 512-1023 byte packets" },
+ { ENETC_PM0_T1518, "MAC tx 1024-1518 byte packets" },
+ { ENETC_PM0_TCNP, "MAC tx control packets" },
+ { ENETC_PM0_TDFR, "MAC tx deferred packets" },
+ { ENETC_PM0_TMCOL, "MAC tx multiple collisions" },
+ { ENETC_PM0_TSCOL, "MAC tx single collisions" },
+ { ENETC_PM0_TLCOL, "MAC tx late collisions" },
+ { ENETC_PM0_TECOL, "MAC tx excessive collisions" },
+ { ENETC_UFDMF, "SI MAC nomatch u-cast discards" },
+ { ENETC_MFDMF, "SI MAC nomatch m-cast discards" },
+ { ENETC_PBFDSIR, "SI MAC nomatch b-cast discards" },
+ { ENETC_PUFDVFR, "SI VLAN nomatch u-cast discards" },
+ { ENETC_PMFDVFR, "SI VLAN nomatch m-cast discards" },
+ { ENETC_PBFDVFR, "SI VLAN nomatch b-cast discards" },
+ { ENETC_PFDMSAPR, "SI pruning discarded frames" },
+ { ENETC_PICDR(0), "ICM DR0 discarded frames" },
+ { ENETC_PICDR(1), "ICM DR1 discarded frames" },
+ { ENETC_PICDR(2), "ICM DR2 discarded frames" },
+ { ENETC_PICDR(3), "ICM DR3 discarded frames" },
+};
+
+static const char rx_ring_stats[][ETH_GSTRING_LEN] = {
+ "Rx ring %2d frames",
+ "Rx ring %2d alloc errors",
+};
+
+static const char tx_ring_stats[][ETH_GSTRING_LEN] = {
+ "Tx ring %2d frames",
+};
+
+static int enetc_get_sset_count(struct net_device *ndev, int sset)
+{
+ struct enetc_ndev_priv *priv = netdev_priv(ndev);
+
+ if (sset == ETH_SS_STATS)
+ return ARRAY_SIZE(enetc_si_counters) +
+ ARRAY_SIZE(tx_ring_stats) * priv->num_tx_rings +
+ ARRAY_SIZE(rx_ring_stats) * priv->num_rx_rings +
+ (enetc_si_is_pf(priv->si) ?
+ ARRAY_SIZE(enetc_port_counters) : 0);
+
+ return -EOPNOTSUPP;
+}
+
+static void enetc_get_strings(struct net_device *ndev, u32 stringset, u8 *data)
+{
+ struct enetc_ndev_priv *priv = netdev_priv(ndev);
+ u8 *p = data;
+ int i, j;
+
+ switch (stringset) {
+ case ETH_SS_STATS:
+ for (i = 0; i < ARRAY_SIZE(enetc_si_counters); i++) {
+ strlcpy(p, enetc_si_counters[i].name, ETH_GSTRING_LEN);
+ p += ETH_GSTRING_LEN;
+ }
+ for (i = 0; i < priv->num_tx_rings; i++) {
+ for (j = 0; j < ARRAY_SIZE(tx_ring_stats); j++) {
+ snprintf(p, ETH_GSTRING_LEN, tx_ring_stats[j],
+ i);
+ p += ETH_GSTRING_LEN;
+ }
+ }
+ for (i = 0; i < priv->num_rx_rings; i++) {
+ for (j = 0; j < ARRAY_SIZE(rx_ring_stats); j++) {
+ snprintf(p, ETH_GSTRING_LEN, rx_ring_stats[j],
+ i);
+ p += ETH_GSTRING_LEN;
+ }
+ }
+
+ if (!enetc_si_is_pf(priv->si))
+ break;
+
+ for (i = 0; i < ARRAY_SIZE(enetc_port_counters); i++) {
+ strlcpy(p, enetc_port_counters[i].name,
+ ETH_GSTRING_LEN);
+ p += ETH_GSTRING_LEN;
+ }
+ break;
+ }
+}
+
+static void enetc_get_ethtool_stats(struct net_device *ndev,
+ struct ethtool_stats *stats, u64 *data)
+{
+ struct enetc_ndev_priv *priv = netdev_priv(ndev);
+ struct enetc_hw *hw = &priv->si->hw;
+ int i, o = 0;
+
+ for (i = 0; i < ARRAY_SIZE(enetc_si_counters); i++)
+ data[o++] = enetc_rd64(hw, enetc_si_counters[i].reg);
+
+ for (i = 0; i < priv->num_tx_rings; i++)
+ data[o++] = priv->tx_ring[i]->stats.packets;
+
+ for (i = 0; i < priv->num_rx_rings; i++) {
+ data[o++] = priv->rx_ring[i]->stats.packets;
+ data[o++] = priv->rx_ring[i]->stats.rx_alloc_errs;
+ }
+
+ if (!enetc_si_is_pf(priv->si))
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(enetc_port_counters); i++)
+ data[o++] = enetc_port_rd(hw, enetc_port_counters[i].reg);
+}
+
static void enetc_get_ringparam(struct net_device *ndev,
struct ethtool_ringparam *ring)
{
@@ -115,6 +296,9 @@ static void enetc_get_ringparam(struct net_device *ndev,
static const struct ethtool_ops enetc_pf_ethtool_ops = {
.get_regs_len = enetc_get_reglen,
.get_regs = enetc_get_regs,
+ .get_sset_count = enetc_get_sset_count,
+ .get_strings = enetc_get_strings,
+ .get_ethtool_stats = enetc_get_ethtool_stats,
.get_ringparam = enetc_get_ringparam,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = phy_ethtool_set_link_ksettings,
@@ -123,6 +307,9 @@ static const struct ethtool_ops enetc_pf_ethtool_ops = {
static const struct ethtool_ops enetc_vf_ethtool_ops = {
.get_regs_len = enetc_get_reglen,
.get_regs = enetc_get_regs,
+ .get_sset_count = enetc_get_sset_count,
+ .get_strings = enetc_get_strings,
+ .get_ethtool_stats = enetc_get_ethtool_stats,
.get_ringparam = enetc_get_ringparam,
};
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_hw.h b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
index 78c0902..511bf5c 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
@@ -34,6 +34,17 @@
#define ENETC_SIPMAR0 0x80
#define ENETC_SIPMAR1 0x84
+/* SI statistics */
+#define ENETC_SIROCT 0x300
+#define ENETC_SIRFRM 0x308
+#define ENETC_SIRUCA 0x310
+#define ENETC_SIRMCA 0x318
+#define ENETC_SITOCT 0x320
+#define ENETC_SITFRM 0x328
+#define ENETC_SITUCA 0x330
+#define ENETC_SITMCA 0x338
+#define ENETC_RBDCR(n) (0x8180 + (n) * 0x200)
+
/* Control BDR regs */
#define ENETC_SICBDRMR 0x800
#define ENETC_SICBDRSR 0x804 /* RO */
@@ -168,6 +179,65 @@ enum enetc_bdr_type {TX, RX};
#define ENETC_PMO_IFM_RG BIT(2)
#define ENETC_PM0_IFM_RLP (BIT(5) | BIT(11))
+/* MAC counters */
+#define ENETC_PM0_REOCT 0x8100
+#define ENETC_PM0_RALN 0x8110
+#define ENETC_PM0_RXPF 0x8118
+#define ENETC_PM0_RFRM 0x8120
+#define ENETC_PM0_RFCS 0x8128
+#define ENETC_PM0_RVLAN 0x8130
+#define ENETC_PM0_RERR 0x8138
+#define ENETC_PM0_RUCA 0x8140
+#define ENETC_PM0_RMCA 0x8148
+#define ENETC_PM0_RBCA 0x8150
+#define ENETC_PM0_RDRP 0x8158
+#define ENETC_PM0_RPKT 0x8160
+#define ENETC_PM0_RUND 0x8168
+#define ENETC_PM0_R64 0x8170
+#define ENETC_PM0_R127 0x8178
+#define ENETC_PM0_R255 0x8180
+#define ENETC_PM0_R511 0x8188
+#define ENETC_PM0_R1023 0x8190
+#define ENETC_PM0_R1518 0x8198
+#define ENETC_PM0_R1519X 0x81A0
+#define ENETC_PM0_ROVR 0x81A8
+#define ENETC_PM0_RJBR 0x81B0
+#define ENETC_PM0_RFRG 0x81B8
+#define ENETC_PM0_RCNP 0x81C0
+#define ENETC_PM0_RDRNTP 0x81C8
+#define ENETC_PM0_TEOCT 0x8200
+#define ENETC_PM0_TOCT 0x8208
+#define ENETC_PM0_TCRSE 0x8210
+#define ENETC_PM0_TXPF 0x8218
+#define ENETC_PM0_TFRM 0x8220
+#define ENETC_PM0_TFCS 0x8228
+#define ENETC_PM0_TVLAN 0x8230
+#define ENETC_PM0_TERR 0x8238
+#define ENETC_PM0_TUCA 0x8240
+#define ENETC_PM0_TMCA 0x8248
+#define ENETC_PM0_TBCA 0x8250
+#define ENETC_PM0_TPKT 0x8260
+#define ENETC_PM0_TUND 0x8268
+#define ENETC_PM0_T127 0x8278
+#define ENETC_PM0_T1023 0x8290
+#define ENETC_PM0_T1518 0x8298
+#define ENETC_PM0_TCNP 0x82C0
+#define ENETC_PM0_TDFR 0x82D0
+#define ENETC_PM0_TMCOL 0x82D8
+#define ENETC_PM0_TSCOL 0x82E0
+#define ENETC_PM0_TLCOL 0x82E8
+#define ENETC_PM0_TECOL 0x82F0
+
+/* Port counters */
+#define ENETC_PICDR(n) (0x0700 + (n) * 8) /* n = [0..3] */
+#define ENETC_PBFDSIR 0x0810
+#define ENETC_PFDMSAPR 0x0814
+#define ENETC_UFDMF 0x1680
+#define ENETC_MFDMF 0x1684
+#define ENETC_PUFDVFR 0x1780
+#define ENETC_PMFDVFR 0x1784
+#define ENETC_PBFDVFR 0x1788
+
/** Global regs, offset: 2_0000h */
#define ENETC_GLOBAL_BASE 0x20000
#define ENETC_G_EIPBRR0 0x0bf8
@@ -186,9 +256,27 @@ struct enetc_hw {
/* general register accessors */
#define enetc_rd_reg(reg) ioread32((reg))
#define enetc_wr_reg(reg, val) iowrite32((val), (reg))
+#ifdef ioread64
+#define enetc_rd_reg64(reg) ioread64((reg))
+#else
+/* using this to read out stats on 32b systems */
+static inline u64 enetc_rd_reg64(void __iomem *reg)
+{
+ u32 low, high, tmp;
+
+ do {
+ high = ioread32(reg + 4);
+ low = ioread32(reg);
+ tmp = ioread32(reg + 4);
+ } while (high != tmp);
+
+ return le64_to_cpu((u64)high << 32 | low);
+}
+#endif
#define enetc_rd(hw, off) enetc_rd_reg((hw)->reg + (off))
#define enetc_wr(hw, off, val) enetc_wr_reg((hw)->reg + (off), val)
+#define enetc_rd64(hw, off) enetc_rd_reg64((hw)->reg + (off))
/* port register accessors - PF only */
#define enetc_port_rd(hw, off) enetc_rd_reg((hw)->port + (off))
#define enetc_port_wr(hw, off, val) enetc_wr_reg((hw)->port + (off), val)
--
2.7.4
^ permalink raw reply related
* [PATCH bpf-next] libbpf: make sure bpf headers are c++ include-able
From: Stanislav Fomichev @ 2018-11-20 18:14 UTC (permalink / raw)
To: netdev, ast, daniel; +Cc: Stanislav Fomichev
Wrap headers in extern "C", to turn off C++ mangling.
This simplifies including libbpf in c++ and linking against it.
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/lib/bpf/bpf.h | 9 +++++++++
tools/lib/bpf/libbpf.h | 9 +++++++++
2 files changed, 18 insertions(+)
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index 26a51538213c..9ea3aec82d8a 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -27,6 +27,10 @@
#include <stdbool.h>
#include <stddef.h>
+#ifdef __cplusplus
+extern "C" {
+#endif
+
#ifndef LIBBPF_API
#define LIBBPF_API __attribute__((visibility("default")))
#endif
@@ -128,4 +132,9 @@ LIBBPF_API int bpf_load_btf(void *btf, __u32 btf_size, char *log_buf,
LIBBPF_API int bpf_task_fd_query(int pid, int fd, __u32 flags, char *buf,
__u32 *buf_len, __u32 *prog_id, __u32 *fd_type,
__u64 *probe_offset, __u64 *probe_addr);
+
+#ifdef __cplusplus
+} /* extern "C" */
+#endif
+
#endif /* __LIBBPF_BPF_H */
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index b1686a787102..74e57e041705 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -16,6 +16,10 @@
#include <sys/types.h> // for size_t
#include <linux/bpf.h>
+#ifdef __cplusplus
+extern "C" {
+#endif
+
#ifndef LIBBPF_API
#define LIBBPF_API __attribute__((visibility("default")))
#endif
@@ -335,4 +339,9 @@ int libbpf_nl_get_qdisc(int sock, unsigned int nl_pid, int ifindex,
libbpf_dump_nlmsg_t dump_qdisc_nlmsg, void *cookie);
int libbpf_nl_get_filter(int sock, unsigned int nl_pid, int ifindex, int handle,
libbpf_dump_nlmsg_t dump_filter_nlmsg, void *cookie);
+
+#ifdef __cplusplus
+} /* extern "C" */
+#endif
+
#endif /* __LIBBPF_LIBBPF_H */
--
2.19.1.1215.g8438c0b245-goog
^ permalink raw reply related
* Re: [Patch net] net: invert the check of detecting hardware RX checksum fault
From: David Miller @ 2018-11-20 18:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiyou.wangcong, herbert, netdev, tom, edumazet, saeedm
In-Reply-To: <ea0aec4d-9051-cd04-4524-bcd747312216@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 19 Nov 2018 17:47:33 -0800
>
>
> On 11/19/2018 05:42 PM, Cong Wang wrote:
>> On Fri, Nov 16, 2018 at 12:15 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>>
>>> On Thu, Nov 15, 2018 at 8:52 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>>
>>>> You could use trafgen to cook such a frame and confirm the theory.
>>>>
>>>> Something like :
>>>
>>> I will try it.
>>
>> I just tried it, it doesn't make much difference, the warning only
>> shows up once after I ran the trafgen script for many times,
>> it could be triggered by other daemons running on the host too.
>
>
> I guess we will need to dump the whole packet for debugging,
> as suggest by Herbert :/
Something like this? Is it safe to linearize here?
diff --git a/net/core/dev.c b/net/core/dev.c
index f2bfd2eda7b2..3955939cc0cf 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3094,6 +3094,8 @@ EXPORT_SYMBOL(__skb_gso_segment);
void netdev_rx_csum_fault(struct net_device *dev, struct sk_buff *skb)
{
if (net_ratelimit()) {
+ static unsigned long last_full_pkt_dump = ~0UL;
+
pr_err("%s: hw csum failure\n", dev ? dev->name : "<unknown>");
if (dev)
pr_err("dev features: %pNF\n", &dev->features);
@@ -3102,6 +3104,13 @@ void netdev_rx_csum_fault(struct net_device *dev, struct sk_buff *skb)
skb_shinfo(skb)->gso_size, skb_shinfo(skb)->gso_type,
skb_shinfo(skb)->nr_frags, skb->ip_summed, skb->csum,
skb->csum_complete_sw, skb->csum_valid, skb->csum_level);
+ if (jiffies - last_full_pkt_dump >= (HZ * 60 * 5) &&
+ !skb_linearize(skb)) {
+ last_full_pkt_dump = jiffies;
+ print_hex_dump(KERN_ERR, "skb data: ",
+ DUMP_PREFIX_OFFSET, 32, 1,
+ skb->data, skb->len, false);
+ }
dump_stack();
}
}
^ permalink raw reply related
* [PATCH net-next] net: don't keep lonely packets forever in the gro hash
From: Paolo Abeni @ 2018-11-20 18:12 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Willem de Bruijn, Eric Dumazet
Eric noted that with UDP GRO and NAPI timeout, we could keep a single
UDP packet inside the GRO hash forever, if the related NAPI instance
calls napi_gro_complete() at an higher frequency than the NAPI timeout.
Willem noted that even TCP packets could be trapped there, till the
next retransmission.
This patch tries to address the issue, flushing the oldest packets before
scheduling the NAPI timeout. The rationale is that such a timeout should be
well below a jiffy and we are not flushing packets eligible for sane GRO.
RFC -> v1:
- added 'Fixes tags', cleaned-up the wording.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Fixes: 3b47d30396ba ("net: gro: add a per device gro flush timer")
Fixes: e20cf8d3f1f7 ("udp: implement GRO for plain UDP sockets.")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
--
Note: since one of the fixed commit is currently only on net-next,
the other one is really old, and the affected scenario without the
more recent commit is really a corner case, targeting net-next.
---
net/core/dev.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 5927f6a7c301..b6eb4e0bfa91 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5975,11 +5975,14 @@ bool napi_complete_done(struct napi_struct *n, int work_done)
if (work_done)
timeout = n->dev->gro_flush_timeout;
+ /* When the NAPI instance uses a timeout, we still need to
+ * somehow bound the time packets are keept in the GRO layer
+ * under heavy traffic
+ */
+ napi_gro_flush(n, !!timeout);
if (timeout)
hrtimer_start(&n->timer, ns_to_ktime(timeout),
HRTIMER_MODE_REL_PINNED);
- else
- napi_gro_flush(n, false);
}
if (unlikely(!list_empty(&n->poll_list))) {
/* If n->poll_list is not empty, we need to mask irqs */
--
2.17.2
^ permalink raw reply related
* Re: [PATCH V2 mlx5-next 00/12] mlx5 core generic EQ API for RDMA ODP
From: Leon Romanovsky @ 2018-11-20 18:11 UTC (permalink / raw)
To: Saeed Mahameed, Jason Gunthorpe
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org
In-Reply-To: <20181119185242.21961-1-saeedm@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]
On Mon, Nov 19, 2018 at 10:52:30AM -0800, Saeed Mahameed wrote:
> Hi,
>
> This patchset is for mlx5-next shared branch, and will be applied there
> once the review is done.
>
> This patchset introduces mostly refactoring work and EQ related code updates to
> allow moving the ODP rdma only logic from mlx5_core into mlx5 ib where it
> belongs, and will allow future updates and optimizations for the rdma ODP
> (On Demand Paging) feature to go only to rdma tree.
>
> Patch #1: Fixes the offsets of stored irq affinity hints inside mlx5
> irq info array.
>
> Patch #2,3,4: Remove unused fields, code and logic
>
> Patch #5: Move all EQ related logic from main.c to eq.c to allow clear
> and seamless refactoring for creating generic EQ management API.
>
> Patch #6: Create mlx5 core EQs in one place, in order to have one entry
> point to call from main file.
>
> Patch #7,8: Move EQ related structures into eq_table mlx5 structure and
> make eq_table fields and logic private to eq.c file.
>
> Patch #9,10: Create one generic EQ struct and use it in different
> EQ types (usages) e.g. (Async, Command, FW pages, completion and ODP)
> Introduce generic EQ API to allow creating Generic EQs regardless of
> their types, will be uesd to create all mlx5 core EQs in mlx5_core and
> ODP EQ in mlx5_ib.
>
> Patch #11: Move ODP logic out from mlx5_core eq.c into mlx5 rdma driver.
> odp.c file.
>
> Patch #12: Make the trivial EQE access methods inline.
>
> v1->v2:
> - Remove vertical alignment
> - Fix spilling "Chip" -> "Cheap"
>
> Thanks,
> Saeed.
>
> ---
>
> Saeed Mahameed (12):
> net/mlx5: EQ, Use the right place to store/read IRQ affinity hint
> net/mlx5: EQ, Remove unused fields and structures
> net/mlx5: EQ, No need to store eq index as a field
> net/mlx5: EQ, Remove redundant completion EQ list lock
> net/mlx5: EQ, Move all EQ logic to eq.c
> net/mlx5: EQ, Create all EQs in one place
> net/mlx5: EQ, irq_info and rmap belong to eq_table
> net/mlx5: EQ, Privatize eq_table and friends
> net/mlx5: EQ, Different EQ types
> net/mlx5: EQ, Generic EQ
> {net,IB}/mlx5: Move Page fault EQ and ODP logic to RDMA
> net/mlx5: EQ, Make EQE access methods inline
>
Pushed to shared mlx5-next:
6d2d6fc83a28 net/mlx5: EQ, Make EQE access methods inline
d5d284b829a6 {net,IB}/mlx5: Move Page fault EQ and ODP logic to RDMA
7701707cb94e net/mlx5: EQ, Generic EQ
16d760839cee net/mlx5: EQ, Different EQ types
f2f3df550139 net/mlx5: EQ, Privatize eq_table and friends
d674a9aa4344 net/mlx5: EQ, irq_info and rmap belong to eq_table
c8e21b3b576b net/mlx5: EQ, Create all EQs in one place
ca828cb4686f net/mlx5: EQ, Move all EQ logic to eq.c
aaa553a64438 net/mlx5: EQ, Remove redundant completion EQ list lock
2883f352571b net/mlx5: EQ, No need to store eq index as a field
4de45c758636 net/mlx5: EQ, Remove unused fields and structures
1e86ace4c140 net/mlx5: EQ, Use the right place to store/read IRQ affinity hint
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] tcp: drop dst in tcp_add_backlog()
From: Eric Dumazet @ 2018-11-20 18:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <20181120.100130.224222181336676011.davem@davemloft.net>
On Tue, Nov 20, 2018 at 10:01 AM David Miller <davem@davemloft.net> wrote:
>
> From: Eric Dumazet <edumazet@google.com>
> Date: Mon, 19 Nov 2018 17:45:55 -0800
>
> > Under stress, softirq rx handler often hits a socket owned by the user,
> > and has to queue the packet into socket backlog.
> >
> > When this happens, skb dst refcount is taken before we escape rcu
> > protected region. This is done from __sk_add_backlog() calling
> > skb_dst_force().
> >
> > Consumer will have to perform the opposite costly operation.
> >
> > AFAIK nothing in tcp stack requests the dst after skb was stored
> > in the backlog. If this was the case, we would have had failures
> > already since skb_dst_force() can end up clearing skb dst anyway.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> Hmmm, it seems to be used by connection completion code to setup the
> socket cached rx dst, right?
>
> For example tcp_finish_connect() --> icsk->icsk_af_ops->sk_rx_dst_set(sk, skb)
We already cope with skb->dst being NULL there I believe.
For reference look at
commit 5037e9ef9454917b047f9f3a19b4dd179fbf7cd4 net: fix IP early demux races
^ permalink raw reply
* Re: [PATCH net-next] tcp: drop dst in tcp_add_backlog()
From: David Miller @ 2018-11-20 18:01 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20181120014555.254608-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 19 Nov 2018 17:45:55 -0800
> Under stress, softirq rx handler often hits a socket owned by the user,
> and has to queue the packet into socket backlog.
>
> When this happens, skb dst refcount is taken before we escape rcu
> protected region. This is done from __sk_add_backlog() calling
> skb_dst_force().
>
> Consumer will have to perform the opposite costly operation.
>
> AFAIK nothing in tcp stack requests the dst after skb was stored
> in the backlog. If this was the case, we would have had failures
> already since skb_dst_force() can end up clearing skb dst anyway.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Hmmm, it seems to be used by connection completion code to setup the
socket cached rx dst, right?
For example tcp_finish_connect() --> icsk->icsk_af_ops->sk_rx_dst_set(sk, skb)
^ permalink raw reply
* [PATCH net] packet: copy user buffers before orphan or clone
From: Willem de Bruijn @ 2018-11-20 18:00 UTC (permalink / raw)
To: netdev; +Cc: davem, johann.baudy, anandhkrishnan, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
tpacket_snd sends packets with user pages linked into skb frags. It
notifies that pages can be reused when the skb is released by setting
skb->destructor to tpacket_destruct_skb.
This can cause data corruption if the skb is orphaned (e.g., on
transmit through veth) or cloned (e.g., on mirror to another psock).
Create a kernel-private copy of data in these cases, same as tun/tap
zerocopy transmission. Reuse that infrastructure: mark the skb as
SKBTX_ZEROCOPY_FRAG, which will trigger copy in skb_orphan_frags(_rx).
Unlike other zerocopy packets, do not set shinfo destructor_arg to
struct ubuf_info. tpacket_destruct_skb already uses that ptr to notify
when the original skb is released and a timestamp is recorded. Do not
change this timestamp behavior. The ubuf_info->callback is not needed
anyway, as no zerocopy notification is expected.
Mark destructor_arg as not-a-uarg by setting the lower bit to 1. The
resulting value is not a valid ubuf_info pointer, nor a valid
tpacket_snd frame address. Add skb_zcopy_.._nouarg helpers for this.
The fix relies on features introduced in commit 52267790ef52 ("sock:
add MSG_ZEROCOPY"), so can be backported as is only to 4.14.
Tested with from `./in_netns.sh ./txring_overwrite` from
http://github.com/wdebruij/kerneltools/tests
Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap")
Reported-by: Anand H. Krishnan <anandhkrishnan@gmail.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
I did not find a better location to store not-a-uarg than in the ptr.
An alternative is to check skb->sk->sk_family. That adds a cacheline
read and needs a helper as skbuff.h does not include sock.h.
---
include/linux/skbuff.h | 18 +++++++++++++++++-
net/packet/af_packet.c | 4 ++--
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 0ba687454267..0d1b2c3f127b 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1326,6 +1326,22 @@ static inline void skb_zcopy_set(struct sk_buff *skb, struct ubuf_info *uarg)
}
}
+static inline void skb_zcopy_set_nouarg(struct sk_buff *skb, void *val)
+{
+ skb_shinfo(skb)->destructor_arg = (void *)((uintptr_t) val | 0x1UL);
+ skb_shinfo(skb)->tx_flags |= SKBTX_ZEROCOPY_FRAG;
+}
+
+static inline bool skb_zcopy_is_nouarg(struct sk_buff *skb)
+{
+ return (uintptr_t) skb_shinfo(skb)->destructor_arg & 0x1UL;
+}
+
+static inline void *skb_zcopy_get_nouarg(struct sk_buff *skb)
+{
+ return (void *)((uintptr_t) skb_shinfo(skb)->destructor_arg & ~0x1UL);
+}
+
/* Release a reference on a zerocopy structure */
static inline void skb_zcopy_clear(struct sk_buff *skb, bool zerocopy)
{
@@ -1335,7 +1351,7 @@ static inline void skb_zcopy_clear(struct sk_buff *skb, bool zerocopy)
if (uarg->callback == sock_zerocopy_callback) {
uarg->zerocopy = uarg->zerocopy && zerocopy;
sock_zerocopy_put(uarg);
- } else {
+ } else if (!skb_zcopy_is_nouarg(skb)) {
uarg->callback(uarg, zerocopy);
}
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index ec3095f13aae..a74650e98f42 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2394,7 +2394,7 @@ static void tpacket_destruct_skb(struct sk_buff *skb)
void *ph;
__u32 ts;
- ph = skb_shinfo(skb)->destructor_arg;
+ ph = skb_zcopy_get_nouarg(skb);
packet_dec_pending(&po->tx_ring);
ts = __packet_set_timestamp(po, ph, skb);
@@ -2461,7 +2461,7 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
skb->mark = po->sk.sk_mark;
skb->tstamp = sockc->transmit_time;
sock_tx_timestamp(&po->sk, sockc->tsflags, &skb_shinfo(skb)->tx_flags);
- skb_shinfo(skb)->destructor_arg = ph.raw;
+ skb_zcopy_set_nouarg(skb, ph.raw);
skb_reserve(skb, hlen);
skb_reset_network_header(skb);
--
2.19.1.1215.g8438c0b245-goog
^ permalink raw reply related
* Re: [PATCH net-next] net_sched: sch_fq: avoid calling ktime_get_ns() if not needed
From: Eric Dumazet @ 2018-11-20 17:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <20181120.095847.465708123173576470.davem@davemloft.net>
On Tue, Nov 20, 2018 at 9:58 AM David Miller <davem@davemloft.net> wrote:
>
> From: Eric Dumazet <edumazet@google.com>
> Date: Mon, 19 Nov 2018 17:30:19 -0800
>
> > There are two cases were we can avoid calling ktime_get_ns() :
> >
> > 1) Queue is empty.
> > 2) Internal queue is not empty.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> Applied.
>
> But just to be clear, if the qdisc is empty we do not need to update
> flow credits etc.?
That is right, nothing needs to be done.
^ permalink raw reply
* Re: [PATCH net-next] net_sched: sch_fq: avoid calling ktime_get_ns() if not needed
From: David Miller @ 2018-11-20 17:58 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20181120013019.236811-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 19 Nov 2018 17:30:19 -0800
> There are two cases were we can avoid calling ktime_get_ns() :
>
> 1) Queue is empty.
> 2) Internal queue is not empty.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
But just to be clear, if the qdisc is empty we do not need to update
flow credits etc.?
^ permalink raw reply
* net: thunderx: nicvf_xdp_setup error code path
From: Lorenzo Bianconi @ 2018-11-20 17:56 UTC (permalink / raw)
To: netdev; +Cc: sgoutham
Hi all,
looking at thunderx XDP support I noticed that nic->xdp_prog pointer in
nicvf_xdp_setup is not actually set to NULL if bpf_prog_add fails but it
is initialized with bpf_prog_add error code. xdp_prog pointer value is used in
the driver to verify if XDP is currently enabled.
Moreover nicvf_xdp_setup does not report to the userspace any error code in
case of failure.
I wrote the following patch to fix the reported issues. Please note I just
compiled it, not actually tested since I have no thunderx nic at the moment.
@Sunil: could you please give it a whirl? If it is ok I will post a formal
patch, thanks
Regards,
Lorenzo
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 768f584f8392..88f8a8fa93cd 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -1784,6 +1784,7 @@ static int nicvf_xdp_setup(struct nicvf *nic, struct bpf_prog *prog)
bool if_up = netif_running(nic->netdev);
struct bpf_prog *old_prog;
bool bpf_attached = false;
+ int ret = 0;
/* For now just support only the usual MTU sized frames */
if (prog && (dev->mtu > 1500)) {
@@ -1817,8 +1818,12 @@ static int nicvf_xdp_setup(struct nicvf *nic, struct bpf_prog *prog)
if (nic->xdp_prog) {
/* Attach BPF program */
nic->xdp_prog = bpf_prog_add(nic->xdp_prog, nic->rx_queues - 1);
- if (!IS_ERR(nic->xdp_prog))
+ if (!IS_ERR(nic->xdp_prog)) {
bpf_attached = true;
+ } else {
+ ret = PTR_ERR(nic->xdp_prog);
+ nic->xdp_prog = NULL;
+ }
}
/* Calculate Tx queues needed for XDP and network stack */
@@ -1830,7 +1835,7 @@ static int nicvf_xdp_setup(struct nicvf *nic, struct bpf_prog *prog)
netif_trans_update(nic->netdev);
}
- return 0;
+ return ret;
}
static int nicvf_xdp(struct net_device *netdev, struct netdev_bpf *xdp)
^ permalink raw reply related
* Re: [PATCH net] tcp: Fix SOF_TIMESTAMPING_RX_HARDWARE to use the latest timestamp during TCP coalescing
From: Eric Dumazet @ 2018-11-20 17:50 UTC (permalink / raw)
To: Stephen Mallon, Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <20181120081502.GA9134@stephen-mallon>
On 11/20/2018 12:15 AM, Stephen Mallon wrote:
> During tcp coalescing ensure that the skb hardware timestamp refers to the
> highest sequence number data.
> Previously only the software timestamp was updated during coalescing.
>
> Signed-off-by: Stephen Mallon <stephen.mallon@sydney.edu.au>
> ---
> net/ipv4/tcp_input.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 2868ef28ce52..e695584bb33f 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -4363,6 +4363,7 @@ static bool tcp_try_coalesce(struct sock *sk,
> if (TCP_SKB_CB(from)->has_rxtstamp) {
> TCP_SKB_CB(to)->has_rxtstamp = true;
> to->tstamp = from->tstamp;
> + skb_hwtstamps(to)->hwtstamp = skb_hwtstamps(from)->hwtstamp;
> }
>
> return true;
>
SGTM, thanks !
Signed-off-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* [PATCH v2 net-next] net: lpc_eth: fix trivial comment typo
From: Andrea Claudi @ 2018-11-20 17:30 UTC (permalink / raw)
To: netdev, davem, vz
Fix comment typo rxfliterctrl -> rxfilterctrl
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
---
drivers/net/ethernet/nxp/lpc_eth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index bd8695a4faaa..89d17399fb5a 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -280,7 +280,7 @@
#define LPC_FCCR_MIRRORCOUNTERCURRENT(n) ((n) & 0xFFFF)
/*
- * rxfliterctrl, rxfilterwolstatus, and rxfilterwolclear shared
+ * rxfilterctrl, rxfilterwolstatus, and rxfilterwolclear shared
* register definitions
*/
#define LPC_RXFLTRW_ACCEPTUNICAST (1 << 0)
@@ -291,7 +291,7 @@
#define LPC_RXFLTRW_ACCEPTPERFECT (1 << 5)
/*
- * rxfliterctrl register definitions
+ * rxfilterctrl register definitions
*/
#define LPC_RXFLTRWSTS_MAGICPACKETENWOL (1 << 12)
#define LPC_RXFLTRWSTS_RXFILTERENWOL (1 << 13)
--
2.17.2
^ permalink raw reply related
* Re: [PATCH V2 mlx5-next 11/12] {net,IB}/mlx5: Move Page fault EQ and ODP logic to RDMA
From: Jason Gunthorpe @ 2018-11-20 17:30 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Leon Romanovsky, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org
In-Reply-To: <20181119185242.21961-12-saeedm@mellanox.com>
On Mon, Nov 19, 2018 at 10:52:41AM -0800, Saeed Mahameed wrote:
> Use the new generic EQ API to move all ODP RDMA data structures and logic
> form mlx5 core driver into mlx5_ib driver.
>
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
> Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
> ---
> drivers/infiniband/hw/mlx5/main.c | 10 +-
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 15 +-
> drivers/infiniband/hw/mlx5/odp.c | 281 +++++++++++++++++-
> drivers/net/ethernet/mellanox/mlx5/core/dev.c | 34 ---
> drivers/net/ethernet/mellanox/mlx5/core/eq.c | 252 ----------------
> .../net/ethernet/mellanox/mlx5/core/lib/eq.h | 8 -
> .../net/ethernet/mellanox/mlx5/core/main.c | 17 +-
> .../ethernet/mellanox/mlx5/core/mlx5_core.h | 2 -
> include/linux/mlx5/driver.h | 49 ---
> include/linux/mlx5/eq.h | 21 ++
> 10 files changed, 308 insertions(+), 381 deletions(-)
Acked-by: Jason Gunthorpe <jgg@mellanox.com>
Can you let me know when these land in the shared branch please?
Thanks,
Jason
^ 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