* [PATCH iproute] devlink: replace print macros with functions
From: Stephen Hemminger @ 2019-06-26 16:20 UTC (permalink / raw)
To: arkadis; +Cc: netdev, Stephen Hemminger
Using functions is safer than macros, and printing is not performance
critical.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
devlink/devlink.c | 62 ++++++++++++++++++++++++++++++++---------------
1 file changed, 42 insertions(+), 20 deletions(-)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index 559f624e3666..4e277f7b0bc3 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -11,6 +11,7 @@
#include <stdio.h>
#include <stdlib.h>
+#include <stdarg.h>
#include <string.h>
#include <stdbool.h>
#include <unistd.h>
@@ -48,32 +49,53 @@
#define HEALTH_REPORTER_TIMESTAMP_FMT_LEN 80
static int g_new_line_count;
-
-#define pr_err(args...) fprintf(stderr, ##args)
-#define pr_out(args...) \
- do { \
- if (g_indent_newline) { \
- fprintf(stdout, "%s", g_indent_str); \
- g_indent_newline = false; \
- } \
- fprintf(stdout, ##args); \
- g_new_line_count = 0; \
- } while (0)
-
-#define pr_out_sp(num, args...) \
- do { \
- int ret = fprintf(stdout, ##args); \
- if (ret < num) \
- fprintf(stdout, "%*s", num - ret, ""); \
- g_new_line_count = 0; \
- } while (0)
-
static int g_indent_level;
static bool g_indent_newline;
+
#define INDENT_STR_STEP 2
#define INDENT_STR_MAXLEN 32
static char g_indent_str[INDENT_STR_MAXLEN + 1] = "";
+static void __attribute__((format(printf, 1, 2)))
+pr_err(const char *fmt, ...)
+{
+ va_list ap;
+
+ va_start(ap, fmt);
+ vfprintf(stderr, fmt, ap);
+ va_end(ap);
+}
+
+static void __attribute__((format(printf, 1, 2)))
+pr_out(const char *fmt, ...)
+{
+ va_list ap;
+
+ if (g_indent_newline) {
+ printf("%s", g_indent_str);
+ g_indent_newline = false;
+ }
+ va_start(ap, fmt);
+ vprintf(fmt, ap);
+ va_end(ap);
+ g_new_line_count = 0;
+}
+
+static void __attribute__((format(printf, 2, 3)))
+pr_out_sp(unsigned int num, const char *fmt, ...)
+{
+ va_list ap;
+ int ret;
+
+ va_start(ap, fmt);
+ ret = vprintf(fmt, ap);
+ va_end(ap);
+
+ if (ret < num)
+ printf("%*s", num - ret, "");
+ g_new_line_count = 0; \
+}
+
static void __pr_out_indent_inc(void)
{
if (g_indent_level + INDENT_STR_STEP > INDENT_STR_MAXLEN)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next 2/5] net: sched: em_ipt: set the family based on the protocol when matching
From: Eyal Birger @ 2019-06-26 16:22 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: netdev, roopa, pablo, xiyou.wangcong, davem, jiri, jhs
In-Reply-To: <9a3be271-af15-3fef-9612-7a3232d09b32@cumulusnetworks.com>
On Wed, 26 Jun 2019 16:45:28 +0300
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
> On 26/06/2019 16:33, Eyal Birger wrote:
> > Hi Nikolay,
> >
> > On Wed, 26 Jun 2019 14:58:52 +0300
> > Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
> >
> >> Set the family based on the protocol otherwise protocol-neutral
> >> matches will have wrong information (e.g. NFPROTO_UNSPEC). In
> >> preparation for using NFPROTO_UNSPEC xt matches.
> >>
> >> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> >> ---
> >> net/sched/em_ipt.c | 4 +++-
> >> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>
...
> >> - nf_hook_state_init(&state, im->hook, im->match->family,
> >> + nf_hook_state_init(&state, im->hook, state.pf,
> >> indev ?: skb->dev, skb->dev, NULL,
> >> em->net, NULL);
> >> acpar.match = im->match;
> >
> > I think this change is incompatible with current behavior.
> >
> > Consider the 'policy' match which matches the packet's xfrm state
> > (sec_path) with the provided user space parameters. The sec_path
> > includes information about the encapsulating packet's parameters
> > whereas the current skb points to the encapsulated packet, and the
> > match is done on the encapsulating packet's info.
> >
> > So if you have an IPv6 packet encapsulated within an IPv4 packet,
> > the match parameters should be done using IPv4 parameters, not IPv6.
> >
> > Maybe use the packet's family only if the match family is UNSPEC?
> >
> > Eyal.
> >
>
> Hi Eyal,
> I see your point, I was wondering about the xfrm cases. :)
> In such case I think we can simplify the set and do it only on UNSPEC
> matches as you suggest.
>
> Maybe we should enforce the tc protocol based on the user-specified
> nfproto at least from iproute2 otherwise people can add mismatching
> rules (e.g. nfproto == v6, tc proto == v4).
>
Hi Nik,
I think for iproute2 the issue is the same. For encapsulated IPv6 in
IPv4 for example, tc proto will be IPv6 (tc sees the encapsulated
packet after decryption) whereas nfproto will be IPv4 (policy match is
done on the encapsulating state metadata which is IPv4).
I think the part missing in iproute2 is the ability to specify
NFPROTO_UNSPEC.
Thanks,
Eyal
^ permalink raw reply
* Re: [PATCH net-next v3 0/8] net: aquantia: implement vlan offloads
From: David Miller @ 2019-06-26 16:26 UTC (permalink / raw)
To: Igor.Russkikh; +Cc: netdev
In-Reply-To: <cover.1561552290.git.igor.russkikh@aquantia.com>
From: Igor Russkikh <Igor.Russkikh@aquantia.com>
Date: Wed, 26 Jun 2019 12:35:30 +0000
> This patchset introduces hardware VLAN offload support and also does some
> maintenance: we replace driver version with uts version string, add
> documentation file for atlantic driver, and update maintainers
> adding Igor as a maintainer.
>
> v3: shuffle doc sections, per Andrew's comments
>
> v2: updates in doc, gpl spdx tag cleanup
This looks good to me, I'll let Andrew et al. have one last chance at re-review.
^ permalink raw reply
* Re: [PATCH bpf-next V6 00/16] AF_XDP infrastructure improvements and mlx5e support
From: Björn Töpel @ 2019-06-26 16:29 UTC (permalink / raw)
To: Tariq Toukan
Cc: Alexei Starovoitov, Daniel Borkmann, Björn Töpel,
Magnus Karlsson, bpf@vger.kernel.org, netdev@vger.kernel.org,
Jonathan Lemon, David S. Miller, Maxim Mikityanskiy
In-Reply-To: <1561559738-4213-1-git-send-email-tariqt@mellanox.com>
On Wed, 26 Jun 2019 at 16:36, Tariq Toukan <tariqt@mellanox.com> wrote:
>
> This series contains improvements to the AF_XDP kernel infrastructure
> and AF_XDP support in mlx5e. The infrastructure improvements are
> required for mlx5e, but also some of them benefit to all drivers, and
> some can be useful for other drivers that want to implement AF_XDP.
>
> The performance testing was performed on a machine with the following
> configuration:
>
> - 24 cores of Intel Xeon E5-2620 v3 @ 2.40 GHz
> - Mellanox ConnectX-5 Ex with 100 Gbit/s link
>
> The results with retpoline disabled, single stream:
>
> txonly: 33.3 Mpps (21.5 Mpps with queue and app pinned to the same CPU)
> rxdrop: 12.2 Mpps
> l2fwd: 9.4 Mpps
>
> The results with retpoline enabled, single stream:
>
> txonly: 21.3 Mpps (14.1 Mpps with queue and app pinned to the same CPU)
> rxdrop: 9.9 Mpps
> l2fwd: 6.8 Mpps
>
> v2 changes:
>
> Added patches for mlx5e and addressed the comments for v1. Rebased for
> bpf-next.
>
> v3 changes:
>
> Rebased for the newer bpf-next, resolved conflicts in libbpf. Addressed
> Björn's comments for coding style. Fixed a bug in error handling flow in
> mlx5e_open_xsk.
>
> v4 changes:
>
> UAPI is not changed, XSK RX queues are exposed to the kernel. The lower
> half of the available amount of RX queues are regular queues, and the
> upper half are XSK RX queues. The patch "xsk: Extend channels to support
> combined XSK/non-XSK traffic" was dropped. The final patch was reworked
> accordingly.
>
> Added "net/mlx5e: Attach/detach XDP program safely", as the changes
> introduced in the XSK patch base on the stuff from this one.
>
> Added "libbpf: Support drivers with non-combined channels", which aligns
> the condition in libbpf with the condition in the kernel.
>
> Rebased over the newer bpf-next.
>
> v5 changes:
>
> In v4, ethtool reports the number of channels as 'combined' and the
> number of XSK RX queues as 'rx' for mlx5e. It was changed, so that 'rx'
> is 0, and 'combined' reports the double amount of channels if there is
> an active UMEM - to make libbpf happy.
>
> The patch for libbpf was dropped. Although it's still useful and fixes
> things, it raises some disagreement, so I'm dropping it - it's no longer
> useful for mlx5e anymore after the change above.
>
> v6 changes:
>
> As Maxim is out of office, I rebased the series on behalf of him,
> solved some conflicts, and re-spinned.
>
> Series generated against bpf-next commit:
> 572a6928f9e3 xdp: Make __mem_id_disconnect static
>
Thanks Tariq, re-adding my ack for the series.
Acked-by: Björn Töpel <bjorn.topel@intel.com>
>
> Maxim Mikityanskiy (16):
> net/mlx5e: Attach/detach XDP program safely
> xsk: Add API to check for available entries in FQ
> xsk: Add getsockopt XDP_OPTIONS
> libbpf: Support getsockopt XDP_OPTIONS
> xsk: Change the default frame size to 4096 and allow controlling it
> xsk: Return the whole xdp_desc from xsk_umem_consume_tx
> net/mlx5e: Replace deprecated PCI_DMA_TODEVICE
> net/mlx5e: Calculate linear RX frag size considering XSK
> net/mlx5e: Allow ICO SQ to be used by multiple RQs
> net/mlx5e: Refactor struct mlx5e_xdp_info
> net/mlx5e: Share the XDP SQ for XDP_TX between RQs
> net/mlx5e: XDP_TX from UMEM support
> net/mlx5e: Consider XSK in XDP MTU limit calculation
> net/mlx5e: Encapsulate open/close queues into a function
> net/mlx5e: Move queue param structs to en/params.h
> net/mlx5e: Add XSK zero-copy support
>
> drivers/net/ethernet/intel/i40e/i40e_xsk.c | 12 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 15 +-
> drivers/net/ethernet/mellanox/mlx5/core/Makefile | 2 +-
> drivers/net/ethernet/mellanox/mlx5/core/en.h | 155 ++++-
> .../net/ethernet/mellanox/mlx5/core/en/params.c | 108 +--
> .../net/ethernet/mellanox/mlx5/core/en/params.h | 118 +++-
> drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 231 +++++--
> drivers/net/ethernet/mellanox/mlx5/core/en/xdp.h | 36 +-
> .../ethernet/mellanox/mlx5/core/en/xsk/Makefile | 1 +
> .../net/ethernet/mellanox/mlx5/core/en/xsk/rx.c | 192 ++++++
> .../net/ethernet/mellanox/mlx5/core/en/xsk/rx.h | 27 +
> .../net/ethernet/mellanox/mlx5/core/en/xsk/setup.c | 223 +++++++
> .../net/ethernet/mellanox/mlx5/core/en/xsk/setup.h | 25 +
> .../net/ethernet/mellanox/mlx5/core/en/xsk/tx.c | 111 ++++
> .../net/ethernet/mellanox/mlx5/core/en/xsk/tx.h | 15 +
> .../net/ethernet/mellanox/mlx5/core/en/xsk/umem.c | 267 ++++++++
> .../net/ethernet/mellanox/mlx5/core/en/xsk/umem.h | 31 +
> .../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 25 +-
> .../ethernet/mellanox/mlx5/core/en_fs_ethtool.c | 18 +-
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 730 +++++++++++++--------
> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 12 +-
> drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 104 ++-
> drivers/net/ethernet/mellanox/mlx5/core/en_stats.c | 115 +++-
> drivers/net/ethernet/mellanox/mlx5/core/en_stats.h | 30 +
> drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 42 +-
> .../net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c | 14 +-
> drivers/net/ethernet/mellanox/mlx5/core/wq.h | 5 -
> include/net/xdp_sock.h | 27 +-
> include/uapi/linux/if_xdp.h | 8 +
> net/xdp/xsk.c | 36 +-
> net/xdp/xsk_queue.h | 14 +
> samples/bpf/xdpsock_user.c | 44 +-
> tools/include/uapi/linux/if_xdp.h | 8 +
> tools/lib/bpf/xsk.c | 12 +
> tools/lib/bpf/xsk.h | 2 +-
> 35 files changed, 2331 insertions(+), 484 deletions(-)
> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/Makefile
> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c
> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.h
> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.h
> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c
> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.h
> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/umem.c
> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/umem.h
>
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH net-next 01/10] net: stmmac: dwxgmac: Enable EDMA by default
From: David Miller @ 2019-06-26 16:33 UTC (permalink / raw)
To: Jose.Abreu
Cc: linux-kernel, netdev, Joao.Pinto, peppe.cavallaro,
alexandre.torgue
In-Reply-To: <6df599b8c2d57db9d82e42861ce897d7cf003424.1561556555.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Wed, 26 Jun 2019 15:47:35 +0200
> @@ -122,6 +122,8 @@ static void dwxgmac2_dma_axi(void __iomem *ioaddr, struct stmmac_axi *axi)
> }
>
> writel(value, ioaddr + XGMAC_DMA_SYSBUS_MODE);
> + writel(GENMASK(29, 0), ioaddr + XGMAC_TX_EDMA_CTRL);
> + writel(GENMASK(29, 0), ioaddr + XGMAC_RX_EDMA_CTRL);
> }
This mask is magic and there is no indication what the bits mean and
in particular what it means to set bits 0 -- 29
You have to document what these bits mean and thus what these register
writes actually do.
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] net: sched: em_ipt: keep the user-specified nfproto and use it
From: nikolay @ 2019-06-26 16:33 UTC (permalink / raw)
To: Eyal Birger; +Cc: netdev, roopa, pablo, xiyou.wangcong, davem, jiri, jhs
In-Reply-To: <20190626191835.1e306147@eyal-ubuntu>
On 26 June 2019 19:18:35 EEST, Eyal Birger <eyal.birger@gmail.com> wrote:
>Hi Nik,
>
>On Wed, 26 Jun 2019 18:56:14 +0300
>Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
>
>> For NFPROTO_UNSPEC xt_matches there's no way to restrict the matching
>> to a specific family, in order to do so we record the user-specified
>> family and later enforce it while doing the match.
>>
>> v2: adjust changes to missing patch, was patch 04 in v1
>>
>> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>> ---
>> net/sched/em_ipt.c | 17 +++++++++++++++--
>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>
>..snip..
>> @@ -182,8 +195,8 @@ static int em_ipt_match(struct sk_buff *skb,
>> struct tcf_ematch *em, const struct em_ipt_match *im = (const void
>> *)em->data; struct xt_action_param acpar = {};
>> struct net_device *indev = NULL;
>> - u8 nfproto = im->match->family;
>> struct nf_hook_state state;
>> + u8 nfproto = im->nfproto;
>
>Maybe I'm missing something now - but it's not really clear to me now
>why keeping im->nfproto would be useful:
>
>If NFPROTO_UNSPEC was provided by userspace then the actual nfproto
>used
>will be taken from the packet, and if NFPROTO_IPV4/IPV6 was specified
>from userspace then it will equal im->match->family.
>
>Is there any case where the resulting nfproto would differ as a result
>of this patch?
>
>Otherwise the patchset looks excellent to me.
>
>Thanks!
>Eyal.
Hi,
It's needed to limit the match only to the user-specified family
for unspec xt matches. The problem is otherwise im->match->family
stays at nfproto_unspec regardless of the user choice.
Thanks for reviewing the set.
Cheers,
Nik
^ permalink raw reply
* Re: XDP multi-buffer incl. jumbo-frames (Was: [RFC V1 net-next 1/1] net: ena: implement XDP drop support)
From: Jesper Dangaard Brouer @ 2019-06-26 16:36 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Machulsky, Zorik, Jubran, Samih, davem@davemloft.net,
netdev@vger.kernel.org, Woodhouse, David, Matushevsky, Alexander,
Bshara, Saeed, Wilson, Matt, Liguori, Anthony, Bshara, Nafea,
Tzalik, Guy, Belgazal, Netanel, Saidi, Ali,
Herrenschmidt, Benjamin, Kiyanovski, Arthur, Daniel Borkmann,
Ilias Apalodimas, Alexei Starovoitov, Jakub Kicinski,
xdp-newbies@vger.kernel.org, brouer
In-Reply-To: <87ef3gbcpz.fsf@toke.dk>
On Wed, 26 Jun 2019 17:14:32 +0200
Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> Jesper Dangaard Brouer <brouer@redhat.com> writes:
>
> > On Wed, 26 Jun 2019 13:52:16 +0200
> > Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> >
> >> Jesper Dangaard Brouer <brouer@redhat.com> writes:
> >>
> >> > On Tue, 25 Jun 2019 03:19:22 +0000
> >> > "Machulsky, Zorik" <zorik@amazon.com> wrote:
> >> >
> >> >> On 6/23/19, 7:21 AM, "Jesper Dangaard Brouer" <brouer@redhat.com> wrote:
> >> >>
> >> >> On Sun, 23 Jun 2019 10:06:49 +0300 <sameehj@amazon.com> wrote:
> >> >>
> >> >> > This commit implements the basic functionality of drop/pass logic in the
> >> >> > ena driver.
> >> >>
> >> >> Usually we require a driver to implement all the XDP return codes,
> >> >> before we accept it. But as Daniel and I discussed with Zorik during
> >> >> NetConf[1], we are going to make an exception and accept the driver
> >> >> if you also implement XDP_TX.
> >> >>
> >> >> As we trust that Zorik/Amazon will follow and implement XDP_REDIRECT
> >> >> later, given he/you wants AF_XDP support which requires XDP_REDIRECT.
> >> >>
> >> >> Jesper, thanks for your comments and very helpful discussion during
> >> >> NetConf! That's the plan, as we agreed. From our side I would like to
> >> >> reiterate again the importance of multi-buffer support by xdp frame.
> >> >> We would really prefer not to see our MTU shrinking because of xdp
> >> >> support.
> >> >
> >> > Okay we really need to make a serious attempt to find a way to support
> >> > multi-buffer packets with XDP. With the important criteria of not
> >> > hurting performance of the single-buffer per packet design.
> >> >
> >> > I've created a design document[2], that I will update based on our
> >> > discussions: [2] https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp-multi-buffer01-design.org
> >> >
> >> > The use-case that really convinced me was Eric's packet header-split.
> >> >
> >> >
> >> > Lets refresh: Why XDP don't have multi-buffer support:
> >> >
> >> > XDP is designed for maximum performance, which is why certain driver-level
> >> > use-cases were not supported, like multi-buffer packets (like jumbo-frames).
> >> > As it e.g. complicated the driver RX-loop and memory model handling.
> >> >
> >> > The single buffer per packet design, is also tied into eBPF Direct-Access
> >> > (DA) to packet data, which can only be allowed if the packet memory is in
> >> > contiguous memory. This DA feature is essential for XDP performance.
> >> >
> >> >
> >> > One way forward is to define that XDP only get access to the first
> >> > packet buffer, and it cannot see subsequent buffers. For XDP_TX and
> >> > XDP_REDIRECT to work then XDP still need to carry pointers (plus
> >> > len+offset) to the other buffers, which is 16 bytes per extra buffer.
> >>
> >> Yeah, I think this would be reasonable. As long as we can have a
> >> metadata field with the full length + still give XDP programs the
> >> ability to truncate the packet (i.e., discard the subsequent pages)
> >
> > You touch upon some interesting complications already:
> >
> > 1. It is valuable for XDP bpf_prog to know "full" length?
> > (if so, then we need to extend xdp ctx with info)
> >
> > But if we need to know the full length, when the first-buffer is
> > processed. Then realize that this affect the drivers RX-loop, because
> > then we need to "collect" all the buffers before we can know the
> > length (although some HW provide this in first descriptor).
> >
> > We likely have to change drivers RX-loop anyhow, as XDP_TX and
> > XDP_REDIRECT will also need to "collect" all buffers before the packet
> > can be forwarded. (Although this could potentially happen later in
> > driver loop when it meet/find the End-Of-Packet descriptor bit).
>
> A few more points (mostly thinking out loud here):
>
> - In any case we probably need to loop through the subsequent
> descriptors in all cases, right? (i.e., if we run XDP on first
> segment, and that returns DROP, the rest that are part of the packet
> still need to be discarded). So we may as well delay XDP execution
> until we have the whole packet?
For the XDP_DROP case, drivers usually have way to discard remaining
buffers/segments, to handle error cases. But it heavily depend on the
driver, how tricky/convoluted this code is...
Generally I would say it would make sense to delay XDP execution until
all buffers/segments are "collected". It would be the clean approach,
but will likely require refactoring of driver level code.
> - Will this allow us to run XDP on hardware-assembled GRO super-packets?
Big YES. This is usually called LRO or TSO packets. And yes, I also
want to support this use-case, which is also listed in [2]. If we go
down this road, this use-case is also important. (Especially related to
my alloc SKBs outside drivers[3], this is a hardware offload we must
support).
[2] https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp-multi-buffer01-design.org
[3] http://vger.kernel.org/netconf2019_files/xdp-metadata-discussion.pdf
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next 2/5] net: sched: em_ipt: set the family based on the protocol when matching
From: nikolay @ 2019-06-26 16:38 UTC (permalink / raw)
To: Eyal Birger; +Cc: netdev, roopa, pablo, xiyou.wangcong, davem, jiri, jhs
In-Reply-To: <20190626192254.2bd41a40@eyal-ubuntu>
On 26 June 2019 19:22:54 EEST, Eyal Birger <eyal.birger@gmail.com> wrote:
>On Wed, 26 Jun 2019 16:45:28 +0300
>Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
>
>> On 26/06/2019 16:33, Eyal Birger wrote:
>> > Hi Nikolay,
>> >
>> > On Wed, 26 Jun 2019 14:58:52 +0300
>> > Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
>> >
>> >> Set the family based on the protocol otherwise protocol-neutral
>> >> matches will have wrong information (e.g. NFPROTO_UNSPEC). In
>> >> preparation for using NFPROTO_UNSPEC xt matches.
>> >>
>> >> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>> >> ---
>> >> net/sched/em_ipt.c | 4 +++-
>> >> 1 file changed, 3 insertions(+), 1 deletion(-)
>> >>
>...
>> >> - nf_hook_state_init(&state, im->hook, im->match->family,
>> >> + nf_hook_state_init(&state, im->hook, state.pf,
>> >> indev ?: skb->dev, skb->dev, NULL,
>> >> em->net, NULL);
>> >> acpar.match = im->match;
>> >
>> > I think this change is incompatible with current behavior.
>> >
>> > Consider the 'policy' match which matches the packet's xfrm state
>> > (sec_path) with the provided user space parameters. The sec_path
>> > includes information about the encapsulating packet's parameters
>> > whereas the current skb points to the encapsulated packet, and the
>> > match is done on the encapsulating packet's info.
>> >
>> > So if you have an IPv6 packet encapsulated within an IPv4 packet,
>> > the match parameters should be done using IPv4 parameters, not
>IPv6.
>> >
>> > Maybe use the packet's family only if the match family is UNSPEC?
>> >
>> > Eyal.
>> >
>>
>> Hi Eyal,
>> I see your point, I was wondering about the xfrm cases. :)
>> In such case I think we can simplify the set and do it only on UNSPEC
>> matches as you suggest.
>>
>> Maybe we should enforce the tc protocol based on the user-specified
>> nfproto at least from iproute2 otherwise people can add mismatching
>> rules (e.g. nfproto == v6, tc proto == v4).
>>
>Hi Nik,
>
>I think for iproute2 the issue is the same. For encapsulated IPv6 in
>IPv4 for example, tc proto will be IPv6 (tc sees the encapsulated
>packet after decryption) whereas nfproto will be IPv4 (policy match is
>done on the encapsulating state metadata which is IPv4).
>
>I think the part missing in iproute2 is the ability to specify
>NFPROTO_UNSPEC.
>
>Thanks,
>Eyal
Right, I answered too quickly, it makes sense to mix them for xt policy.
I also plan to add support for clsact, it should be trivial and iproute2-only
change.
Thanks,
Nik
^ permalink raw reply
* Re: XDP multi-buffer incl. jumbo-frames (Was: [RFC V1 net-next 1/1] net: ena: implement XDP drop support)
From: Jonathan Lemon @ 2019-06-26 16:42 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Toke Høiland-Jørgensen, Jesper Dangaard Brouer,
Machulsky, Zorik, Jubran, Samih, davem, netdev, Woodhouse, David,
Matushevsky, Alexander, Bshara, Saeed, Wilson, Matt,
Liguori, Anthony, Bshara, Nafea, Tzalik, Guy, Belgazal, Netanel,
Saidi, Ali, Herrenschmidt, Benjamin, Kiyanovski, Arthur,
Daniel Borkmann, Ilias Apalodimas, Alexei Starovoitov,
Jakub Kicinski, xdp-newbies
In-Reply-To: <CA+FuTSfKnhv9rr=cDa_4m7Dd9qkEm_oabDfyvH0T0sM+fQTU=w@mail.gmail.com>
On 26 Jun 2019, at 8:20, Willem de Bruijn wrote:
> On Wed, Jun 26, 2019 at 11:01 AM Toke Høiland-Jørgensen
> <toke@redhat.com> wrote:
>>
>> Jesper Dangaard Brouer <brouer@redhat.com> writes:
>>
>>> On Wed, 26 Jun 2019 13:52:16 +0200
>>> Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>>
>>>> Jesper Dangaard Brouer <brouer@redhat.com> writes:
>>>>
>>>>> On Tue, 25 Jun 2019 03:19:22 +0000
>>>>> "Machulsky, Zorik" <zorik@amazon.com> wrote:
>>>>>
>>>>>> On 6/23/19, 7:21 AM, "Jesper Dangaard Brouer"
>>>>>> <brouer@redhat.com> wrote:
>>>>>>
>>>>>> On Sun, 23 Jun 2019 10:06:49 +0300 <sameehj@amazon.com>
>>>>>> wrote:
>>>>>>
>>>>>> > This commit implements the basic functionality of drop/pass
>>>>>> logic in the
>>>>>> > ena driver.
>>>>>>
>>>>>> Usually we require a driver to implement all the XDP return
>>>>>> codes,
>>>>>> before we accept it. But as Daniel and I discussed with
>>>>>> Zorik during
>>>>>> NetConf[1], we are going to make an exception and accept the
>>>>>> driver
>>>>>> if you also implement XDP_TX.
>>>>>>
>>>>>> As we trust that Zorik/Amazon will follow and implement
>>>>>> XDP_REDIRECT
>>>>>> later, given he/you wants AF_XDP support which requires
>>>>>> XDP_REDIRECT.
>>>>>>
>>>>>> Jesper, thanks for your comments and very helpful discussion
>>>>>> during
>>>>>> NetConf! That's the plan, as we agreed. From our side I would
>>>>>> like to
>>>>>> reiterate again the importance of multi-buffer support by xdp
>>>>>> frame.
>>>>>> We would really prefer not to see our MTU shrinking because of
>>>>>> xdp
>>>>>> support.
>>>>>
>>>>> Okay we really need to make a serious attempt to find a way to
>>>>> support
>>>>> multi-buffer packets with XDP. With the important criteria of not
>>>>> hurting performance of the single-buffer per packet design.
>>>>>
>>>>> I've created a design document[2], that I will update based on our
>>>>> discussions: [2]
>>>>> https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp-multi-buffer01-design.org
>>>>>
>>>>> The use-case that really convinced me was Eric's packet
>>>>> header-split.
>
> Thanks for starting this discussion Jesper!
>
>>>>>
>>>>>
>>>>> Lets refresh: Why XDP don't have multi-buffer support:
>>>>>
>>>>> XDP is designed for maximum performance, which is why certain
>>>>> driver-level
>>>>> use-cases were not supported, like multi-buffer packets (like
>>>>> jumbo-frames).
>>>>> As it e.g. complicated the driver RX-loop and memory model
>>>>> handling.
>>>>>
>>>>> The single buffer per packet design, is also tied into eBPF
>>>>> Direct-Access
>>>>> (DA) to packet data, which can only be allowed if the packet
>>>>> memory is in
>>>>> contiguous memory. This DA feature is essential for XDP
>>>>> performance.
>>>>>
>>>>>
>>>>> One way forward is to define that XDP only get access to the first
>>>>> packet buffer, and it cannot see subsequent buffers. For XDP_TX
>>>>> and
>>>>> XDP_REDIRECT to work then XDP still need to carry pointers (plus
>>>>> len+offset) to the other buffers, which is 16 bytes per extra
>>>>> buffer.
>>>>
>>>> Yeah, I think this would be reasonable. As long as we can have a
>>>> metadata field with the full length + still give XDP programs the
>>>> ability to truncate the packet (i.e., discard the subsequent pages)
>>>
>>> You touch upon some interesting complications already:
>>>
>>> 1. It is valuable for XDP bpf_prog to know "full" length?
>>> (if so, then we need to extend xdp ctx with info)
>>
>> Valuable, quite likely. A hard requirement, probably not (for all use
>> cases).
>
> Agreed.
>
> One common validation use would be to drop any packets whose header
> length disagrees with the actual packet length.
>
>>> But if we need to know the full length, when the first-buffer is
>>> processed. Then realize that this affect the drivers RX-loop,
>>> because
>>> then we need to "collect" all the buffers before we can know the
>>> length (although some HW provide this in first descriptor).
>>>
>>> We likely have to change drivers RX-loop anyhow, as XDP_TX and
>>> XDP_REDIRECT will also need to "collect" all buffers before the
>>> packet
>>> can be forwarded. (Although this could potentially happen later in
>>> driver loop when it meet/find the End-Of-Packet descriptor bit).
>
> Yes, this might be quite a bit of refactoring of device driver code.
>
> Should we move forward with some initial constraints, e.g., no
> XDP_REDIRECT, no "full" length and no bpf_xdp_adjust_tail?
>
> That already allows many useful programs.
>
> As long as we don't arrive at a design that cannot be extended with
> those features later.
I think collecting all frames until EOP and then processing them
at once sounds reasonable.
>>> 2. Can we even allow helper bpf_xdp_adjust_tail() ?
>>>
>>> Wouldn't it be easier to disallow a BPF-prog with this helper, when
>>> driver have configured multi-buffer?
>>
>> Easier, certainly. But then it's even easier to not implement this at
>> all ;)
>>
>>> Or will it be too restrictive, if jumbo-frame is very uncommon and
>>> only enabled because switch infra could not be changed (like Amazon
>>> case).
>
> Header-split, LRO and jumbo frame are certainly not limited to the
> Amazon case.
>
>> I think it would be preferable to support it; but maybe we can let
>> that
>> depend on how difficult it actually turns out to be to allow it?
>>
>>> Perhaps it is better to let bpf_xdp_adjust_tail() fail runtime?
>>
>> If we do disallow it, I think I'd lean towards failing the call at
>> runtime...
>
> Disagree. I'd rather have a program fail at load if it depends on
> multi-frag support while the (driver) implementation does not yet
> support it.
If all packets are collected together (like the bulk queue does), and
then
passed to XDP, this could easily be made backwards compatible. If the
XDP
program isn't 'multi-frag' aware, then each packet is just passed in
individually.
Of course, passing in the equivalent of a iovec requires some form of
loop
support on the BPF side, doesn't it?
--
Jonathan
^ permalink raw reply
* [PATCH] net/mlx5: remove redundant assignment to ret
From: Colin King @ 2019-06-26 16:44 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky, David S . Miller, netdev,
linux-rdma
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Variable ret is being initialized with a value that is never read and
ret is being re-assigned later on. The initialization is redundant
and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 072b56fda27e..dd47c6d03dad 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -1477,7 +1477,7 @@ static const struct pci_error_handlers mlx5_err_handler = {
static int mlx5_try_fast_unload(struct mlx5_core_dev *dev)
{
bool fast_teardown = false, force_teardown = false;
- int ret = 1;
+ int ret;
fast_teardown = MLX5_CAP_GEN(dev, fast_teardown);
force_teardown = MLX5_CAP_GEN(dev, force_teardown);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH bpf-next V6 00/16] AF_XDP infrastructure improvements and mlx5e support
From: Jonathan Lemon @ 2019-06-26 16:46 UTC (permalink / raw)
To: Tariq Toukan
Cc: Alexei Starovoitov, Daniel Borkmann, bjorn.topel, Magnus Karlsson,
bpf, netdev, David S. Miller, Maxim Mikityanskiy
In-Reply-To: <1561559738-4213-1-git-send-email-tariqt@mellanox.com>
On 26 Jun 2019, at 7:35, Tariq Toukan wrote:
> This series contains improvements to the AF_XDP kernel infrastructure
> and AF_XDP support in mlx5e. The infrastructure improvements are
> required for mlx5e, but also some of them benefit to all drivers, and
> some can be useful for other drivers that want to implement AF_XDP.
>
> The performance testing was performed on a machine with the following
> configuration:
>
> - 24 cores of Intel Xeon E5-2620 v3 @ 2.40 GHz
> - Mellanox ConnectX-5 Ex with 100 Gbit/s link
>
> The results with retpoline disabled, single stream:
>
> txonly: 33.3 Mpps (21.5 Mpps with queue and app pinned to the same
> CPU)
> rxdrop: 12.2 Mpps
> l2fwd: 9.4 Mpps
>
> The results with retpoline enabled, single stream:
>
> txonly: 21.3 Mpps (14.1 Mpps with queue and app pinned to the same
> CPU)
> rxdrop: 9.9 Mpps
> l2fwd: 6.8 Mpps
>
> v2 changes:
>
> Added patches for mlx5e and addressed the comments for v1. Rebased for
> bpf-next.
>
> v3 changes:
>
> Rebased for the newer bpf-next, resolved conflicts in libbpf.
> Addressed
> Björn's comments for coding style. Fixed a bug in error handling flow
> in
> mlx5e_open_xsk.
>
> v4 changes:
>
> UAPI is not changed, XSK RX queues are exposed to the kernel. The
> lower
> half of the available amount of RX queues are regular queues, and the
> upper half are XSK RX queues. The patch "xsk: Extend channels to
> support
> combined XSK/non-XSK traffic" was dropped. The final patch was
> reworked
> accordingly.
>
> Added "net/mlx5e: Attach/detach XDP program safely", as the changes
> introduced in the XSK patch base on the stuff from this one.
>
> Added "libbpf: Support drivers with non-combined channels", which
> aligns
> the condition in libbpf with the condition in the kernel.
>
> Rebased over the newer bpf-next.
>
> v5 changes:
>
> In v4, ethtool reports the number of channels as 'combined' and the
> number of XSK RX queues as 'rx' for mlx5e. It was changed, so that
> 'rx'
> is 0, and 'combined' reports the double amount of channels if there is
> an active UMEM - to make libbpf happy.
>
> The patch for libbpf was dropped. Although it's still useful and fixes
> things, it raises some disagreement, so I'm dropping it - it's no
> longer
> useful for mlx5e anymore after the change above.
>
> v6 changes:
>
> As Maxim is out of office, I rebased the series on behalf of him,
> solved some conflicts, and re-spinned.
If this is just a re-spin, you can add back:
Tested-by: Jonathan Lemon <jonathan.lemon@gmail.com>
>
> Series generated against bpf-next commit:
> 572a6928f9e3 xdp: Make __mem_id_disconnect static
>
>
> Maxim Mikityanskiy (16):
> net/mlx5e: Attach/detach XDP program safely
> xsk: Add API to check for available entries in FQ
> xsk: Add getsockopt XDP_OPTIONS
> libbpf: Support getsockopt XDP_OPTIONS
> xsk: Change the default frame size to 4096 and allow controlling it
> xsk: Return the whole xdp_desc from xsk_umem_consume_tx
> net/mlx5e: Replace deprecated PCI_DMA_TODEVICE
> net/mlx5e: Calculate linear RX frag size considering XSK
> net/mlx5e: Allow ICO SQ to be used by multiple RQs
> net/mlx5e: Refactor struct mlx5e_xdp_info
> net/mlx5e: Share the XDP SQ for XDP_TX between RQs
> net/mlx5e: XDP_TX from UMEM support
> net/mlx5e: Consider XSK in XDP MTU limit calculation
> net/mlx5e: Encapsulate open/close queues into a function
> net/mlx5e: Move queue param structs to en/params.h
> net/mlx5e: Add XSK zero-copy support
>
> drivers/net/ethernet/intel/i40e/i40e_xsk.c | 12 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 15 +-
> drivers/net/ethernet/mellanox/mlx5/core/Makefile | 2 +-
> drivers/net/ethernet/mellanox/mlx5/core/en.h | 155 ++++-
> .../net/ethernet/mellanox/mlx5/core/en/params.c | 108 +--
> .../net/ethernet/mellanox/mlx5/core/en/params.h | 118 +++-
> drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 231 +++++--
> drivers/net/ethernet/mellanox/mlx5/core/en/xdp.h | 36 +-
> .../ethernet/mellanox/mlx5/core/en/xsk/Makefile | 1 +
> .../net/ethernet/mellanox/mlx5/core/en/xsk/rx.c | 192 ++++++
> .../net/ethernet/mellanox/mlx5/core/en/xsk/rx.h | 27 +
> .../net/ethernet/mellanox/mlx5/core/en/xsk/setup.c | 223 +++++++
> .../net/ethernet/mellanox/mlx5/core/en/xsk/setup.h | 25 +
> .../net/ethernet/mellanox/mlx5/core/en/xsk/tx.c | 111 ++++
> .../net/ethernet/mellanox/mlx5/core/en/xsk/tx.h | 15 +
> .../net/ethernet/mellanox/mlx5/core/en/xsk/umem.c | 267 ++++++++
> .../net/ethernet/mellanox/mlx5/core/en/xsk/umem.h | 31 +
> .../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 25 +-
> .../ethernet/mellanox/mlx5/core/en_fs_ethtool.c | 18 +-
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 730
> +++++++++++++--------
> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 12 +-
> drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 104 ++-
> drivers/net/ethernet/mellanox/mlx5/core/en_stats.c | 115 +++-
> drivers/net/ethernet/mellanox/mlx5/core/en_stats.h | 30 +
> drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 42 +-
> .../net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c | 14 +-
> drivers/net/ethernet/mellanox/mlx5/core/wq.h | 5 -
> include/net/xdp_sock.h | 27 +-
> include/uapi/linux/if_xdp.h | 8 +
> net/xdp/xsk.c | 36 +-
> net/xdp/xsk_queue.h | 14 +
> samples/bpf/xdpsock_user.c | 44 +-
> tools/include/uapi/linux/if_xdp.h | 8 +
> tools/lib/bpf/xsk.c | 12 +
> tools/lib/bpf/xsk.h | 2 +-
> 35 files changed, 2331 insertions(+), 484 deletions(-)
> create mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/Makefile
> create mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c
> create mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.h
> create mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
> create mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.h
> create mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c
> create mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.h
> create mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/umem.c
> create mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/umem.h
>
> --
> 1.8.3.1
^ permalink raw reply
* Re: [PATCH] bonding: Always enable vlan tx offload
From: Jiri Pirko @ 2019-06-26 16:48 UTC (permalink / raw)
To: mirq-linux
Cc: YueHaibing, davem, sdf, jianbol, jiri, willemb, sdf, j.vosburgh,
vfalico, andy, linux-kernel, netdev
In-Reply-To: <20190626161337.GA18953@qmqm.qmqm.pl>
Wed, Jun 26, 2019 at 06:13:38PM CEST, mirq-linux@rere.qmqm.pl wrote:
>On Wed, Jun 26, 2019 at 04:08:44PM +0800, YueHaibing wrote:
>> We build vlan on top of bonding interface, which vlan offload
>> is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is
>> BOND_XMIT_POLICY_ENCAP34.
>>
>> Because vlan tx offload is off, vlan tci is cleared and skb push
>> the vlan header in validate_xmit_vlan() while sending from vlan
>> devices. Then in bond_xmit_hash, __skb_flow_dissect() fails to
>> get information from protocol headers encapsulated within vlan,
>> because 'nhoff' is points to IP header, so bond hashing is based
>> on layer 2 info, which fails to distribute packets across slaves.
>>
>> This patch always enable bonding's vlan tx offload, pass the vlan
>> packets to the slave devices with vlan tci, let them to handle
>> vlan implementation.
>[...]
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> index 407f4095a37a..799fc38c5c34 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -4320,12 +4320,12 @@ void bond_setup(struct net_device *bond_dev)
>> bond_dev->features |= NETIF_F_NETNS_LOCAL;
>>
>> bond_dev->hw_features = BOND_VLAN_FEATURES |
>> - NETIF_F_HW_VLAN_CTAG_TX |
>> NETIF_F_HW_VLAN_CTAG_RX |
>> NETIF_F_HW_VLAN_CTAG_FILTER;
>>
>> bond_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL | NETIF_F_GSO_UDP_L4;
>> bond_dev->features |= bond_dev->hw_features;
>> + bond_dev->features |= NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_STAG_TX;
>> }
>>
>> /* Destroy a bonding device.
>>
>
>I can see that bonding driver uses dev_queue_xmit() to pass packets to
>slave links, but I can't see where in the path it does software fallback
>for devices without HW VLAN tagging. Generally drivers that don't ever
>do VLAN offload also ignore vlan_tci presence. Am I missing something
>here?
validate_xmit_skb->validate_xmit_vlan
>
>Best Regards,
>Michał Mirosław
^ permalink raw reply
* Re: [PATCH net-next 14/18] ionic: Add Tx and Rx handling
From: Shannon Nelson @ 2019-06-26 16:49 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190625170803.2a23650b@cakuba.netronome.com>
On 6/25/19 5:08 PM, Jakub Kicinski wrote:
> On Thu, 20 Jun 2019 13:24:20 -0700, Shannon Nelson wrote:
>> Add both the Tx and Rx queue setup and handling. The related
>> stats display come later. Instead of using the generic napi
>> routines used by the slow-path command, the Tx and Rx paths
>> are simplified and inlined in one file in order to get better
>> compiler optimizations.
>>
>> Signed-off-by: Shannon Nelson <snelson@pensando.io>
>> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c b/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
>> index 5ebfaa320edf..6dfcada9e822 100644
>> --- a/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
>> +++ b/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
>> @@ -351,6 +351,54 @@ int ionic_debugfs_add_qcq(struct lif *lif, struct qcq *qcq)
>> desc_blob);
>> }
>>
>> + if (qcq->flags & QCQ_F_TX_STATS) {
>> + stats_dentry = debugfs_create_dir("tx_stats", q_dentry);
>> + if (IS_ERR_OR_NULL(stats_dentry))
>> + return PTR_ERR(stats_dentry);
>> +
>> + debugfs_create_u64("dma_map_err", 0400, stats_dentry,
>> + &qcq->stats->tx.dma_map_err);
>> + debugfs_create_u64("pkts", 0400, stats_dentry,
>> + &qcq->stats->tx.pkts);
>> + debugfs_create_u64("bytes", 0400, stats_dentry,
>> + &qcq->stats->tx.bytes);
>> + debugfs_create_u64("clean", 0400, stats_dentry,
>> + &qcq->stats->tx.clean);
>> + debugfs_create_u64("linearize", 0400, stats_dentry,
>> + &qcq->stats->tx.linearize);
>> + debugfs_create_u64("no_csum", 0400, stats_dentry,
>> + &qcq->stats->tx.no_csum);
>> + debugfs_create_u64("csum", 0400, stats_dentry,
>> + &qcq->stats->tx.csum);
>> + debugfs_create_u64("crc32_csum", 0400, stats_dentry,
>> + &qcq->stats->tx.crc32_csum);
>> + debugfs_create_u64("tso", 0400, stats_dentry,
>> + &qcq->stats->tx.tso);
>> + debugfs_create_u64("frags", 0400, stats_dentry,
>> + &qcq->stats->tx.frags);
> I wonder why debugfs over ethtool -S?
I believe this was from early engineering, before ethtool -S had been
filled out. I'll clean that up.
>
>> +static int ionic_tx(struct queue *q, struct sk_buff *skb)
>> +{
>> + struct tx_stats *stats = q_to_tx_stats(q);
>> + int err;
>> +
>> + if (skb->ip_summed == CHECKSUM_PARTIAL)
>> + err = ionic_tx_calc_csum(q, skb);
>> + else
>> + err = ionic_tx_calc_no_csum(q, skb);
>> + if (err)
>> + return err;
>> +
>> + err = ionic_tx_skb_frags(q, skb);
>> + if (err)
>> + return err;
>> +
>> + skb_tx_timestamp(skb);
>> + stats->pkts++;
>> + stats->bytes += skb->len;
> nit: I think counting stats on completion may be a better idea,
> otherwise when you can a full ring on stop your HW counters are
> guaranteed to be different than SW counters. Am I wrong?
You are not wrong, that is how many drivers handle it. I like seeing
how much the driver was given (ethtool -S) versus how much the HW
actually pushed out (netstat -i or ip -s link show). These numbers
shouldn't be very often be very different, but it is interesting when
they are.
>
>> + ionic_txq_post(q, !netdev_xmit_more(), ionic_tx_clean, skb);
>> +
>> + return 0;
>> +}
>> +
>> +static int ionic_tx_descs_needed(struct queue *q, struct sk_buff *skb)
>> +{
>> + struct tx_stats *stats = q_to_tx_stats(q);
>> + int err;
>> +
>> + /* If TSO, need roundup(skb->len/mss) descs */
>> + if (skb_is_gso(skb))
>> + return (skb->len / skb_shinfo(skb)->gso_size) + 1;
> This doesn't look correct, are you sure you don't want
> skb_shinfo(skb)->gso_segs ?
That would probably work as well.
>
>> +
>> + /* If non-TSO, just need 1 desc and nr_frags sg elems */
>> + if (skb_shinfo(skb)->nr_frags <= IONIC_TX_MAX_SG_ELEMS)
>> + return 1;
>> +
>> + /* Too many frags, so linearize */
>> + err = skb_linearize(skb);
>> + if (err)
>> + return err;
>> +
>> + stats->linearize++;
>> +
>> + /* Need 1 desc and zero sg elems */
>> + return 1;
>> +}
>> +
>> +netdev_tx_t ionic_start_xmit(struct sk_buff *skb, struct net_device *netdev)
>> +{
>> + u16 queue_index = skb_get_queue_mapping(skb);
>> + struct lif *lif = netdev_priv(netdev);
>> + struct queue *q;
>> + int ndescs;
>> + int err;
>> +
>> + if (unlikely(!test_bit(LIF_UP, lif->state))) {
>> + dev_kfree_skb(skb);
>> + return NETDEV_TX_OK;
>> + }
> Surely you stop TX before taking the queues down?
Yes, in ionic_lif_stop()
>
>> + if (likely(lif_to_txqcq(lif, queue_index)))
>> + q = lif_to_txq(lif, queue_index);
>> + else
>> + q = lif_to_txq(lif, 0);
>> +
>> + ndescs = ionic_tx_descs_needed(q, skb);
>> + if (ndescs < 0)
>> + goto err_out_drop;
>> +
>> + if (!ionic_q_has_space(q, ndescs)) {
>> + netif_stop_subqueue(netdev, queue_index);
>> + q->stop++;
>> +
>> + /* Might race with ionic_tx_clean, check again */
>> + smp_rmb();
>> + if (ionic_q_has_space(q, ndescs)) {
>> + netif_wake_subqueue(netdev, queue_index);
>> + q->wake++;
>> + } else {
>> + return NETDEV_TX_BUSY;
>> + }
>> + }
>> +
>> + if (skb_is_gso(skb))
>> + err = ionic_tx_tso(q, skb);
>> + else
>> + err = ionic_tx(q, skb);
>> +
>> + if (err)
>> + goto err_out_drop;
>> +
>> + return NETDEV_TX_OK;
>> +
>> +err_out_drop:
>> + q->drop++;
>> + dev_kfree_skb(skb);
>> + return NETDEV_TX_OK;
>> +}
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] net: sched: em_ipt: keep the user-specified nfproto and use it
From: nikolay @ 2019-06-26 17:02 UTC (permalink / raw)
To: Eyal Birger; +Cc: netdev, roopa, pablo, xiyou.wangcong, davem, jiri, jhs
In-Reply-To: <92B812B3-C5FB-452B-809A-1367349DB29A@cumulusnetworks.com>
On 26 June 2019 19:33:48 EEST, nikolay@cumulusnetworks.com wrote:
>On 26 June 2019 19:18:35 EEST, Eyal Birger <eyal.birger@gmail.com>
>wrote:
>>Hi Nik,
>>
>>On Wed, 26 Jun 2019 18:56:14 +0300
>>Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
>>
>>> For NFPROTO_UNSPEC xt_matches there's no way to restrict the
>matching
>>> to a specific family, in order to do so we record the user-specified
>>> family and later enforce it while doing the match.
>>>
>>> v2: adjust changes to missing patch, was patch 04 in v1
>>>
>>> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>>> ---
>>> net/sched/em_ipt.c | 17 +++++++++++++++--
>>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>>
>>..snip..
>>> @@ -182,8 +195,8 @@ static int em_ipt_match(struct sk_buff *skb,
>>> struct tcf_ematch *em, const struct em_ipt_match *im = (const void
>>> *)em->data; struct xt_action_param acpar = {};
>>> struct net_device *indev = NULL;
>>> - u8 nfproto = im->match->family;
>>> struct nf_hook_state state;
>>> + u8 nfproto = im->nfproto;
>>
>>Maybe I'm missing something now - but it's not really clear to me now
>>why keeping im->nfproto would be useful:
>>
>>If NFPROTO_UNSPEC was provided by userspace then the actual nfproto
>>used
>>will be taken from the packet, and if NFPROTO_IPV4/IPV6 was specified
>>from userspace then it will equal im->match->family.
>>
>>Is there any case where the resulting nfproto would differ as a result
>>of this patch?
>>
>>Otherwise the patchset looks excellent to me.
>>
>>Thanks!
>>Eyal.
>
>Hi,
>It's needed to limit the match only to the user-specified family
>for unspec xt matches. The problem is otherwise im->match->family
>stays at nfproto_unspec regardless of the user choice.
>
>Thanks for reviewing the set.
>
>Cheers,
> Nik
Hm, while that is true, thinking more about it - mixing the user proto and the real proto
could be problematic since we no longer enforce them to be equal, but we check
the network header len based on the packet only and we can end up checking v4
len and parsing it as nfproto v6.
I'll spin v3 with unspec only and we can restrict it later if needed.
^ permalink raw reply
* Re: [PATCH net-next 17/18] ionic: Add RSS support
From: Shannon Nelson @ 2019-06-26 17:04 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190625172054.6a9d22dc@cakuba.netronome.com>
On 6/25/19 5:20 PM, Jakub Kicinski wrote:
> On Thu, 20 Jun 2019 13:24:23 -0700, Shannon Nelson wrote:
>> +static int ionic_lif_rss_init(struct lif *lif)
>> +{
>> + static const u8 toeplitz_symmetric_key[] = {
>> + 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
>> + 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
>> + 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
>> + 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
>> + 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
>> + };
> netdev_rss_key_fill()
Sure.
>
>> + unsigned int i, tbl_sz;
>> +
>> + lif->rss_types = IONIC_RSS_TYPE_IPV4 |
>> + IONIC_RSS_TYPE_IPV4_TCP |
>> + IONIC_RSS_TYPE_IPV4_UDP |
>> + IONIC_RSS_TYPE_IPV6 |
>> + IONIC_RSS_TYPE_IPV6_TCP |
>> + IONIC_RSS_TYPE_IPV6_UDP;
>> +
>> + /* Fill indirection table with 'default' values */
>> + tbl_sz = le16_to_cpu(lif->ionic->ident.lif.eth.rss_ind_tbl_sz);
>> + for (i = 0; i < tbl_sz; i++)
>> + lif->rss_ind_tbl[i] = i % lif->nxqs;
> ethtool_rxfh_indir_default()
Sure
>
>> + return ionic_lif_rss_config(lif, lif->rss_types,
>> + toeplitz_symmetric_key, NULL);
>> +}
Thanks for your time, I appreciate the review.
sln
^ permalink raw reply
* Re: [PATCH net 0/2] net/smc: fixes 2019-06-26
From: David Miller @ 2019-06-26 17:10 UTC (permalink / raw)
To: ubraun
Cc: netdev, linux-s390, gor, heiko.carstens, raspl, kgraul, zhp,
yuehaibing
In-Reply-To: <20190626154750.46127-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Wed, 26 Jun 2019 17:47:48 +0200
> here are 2 small smc fixes for the net tree.
Looks good, series applied, thanks.
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2019-06-26
From: David Miller @ 2019-06-26 17:12 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87ef3gjq16.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Wed, 26 Jun 2019 18:59:49 +0300
> here's a pull request to net-next for 5.3, more info below. Please let
> me know if there are any problems.
Pulled, thanks Kalo.
^ permalink raw reply
* Re: [PATCH] team: Always enable vlan tx offload
From: David Miller @ 2019-06-26 17:14 UTC (permalink / raw)
To: yuehaibing
Cc: sdf, jianbol, jiri, mirq-linux, willemb, sdf, jiri, j.vosburgh,
vfalico, andy, linux-kernel, netdev
In-Reply-To: <20190626160339.35152-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 27 Jun 2019 00:03:39 +0800
> We should rather have vlan_tci filled all the way down
> to the transmitting netdevice and let it do the hw/sw
> vlan implementation.
>
> Suggested-by: Jiri Pirko <jiri@resnulli.us>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v4 net] af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET
From: Neil Horman @ 2019-06-26 17:14 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Network Development, Matteo Croce, David S. Miller
In-Reply-To: <CAF=yD-+_khMRCK0gE2q7nAi8fAtwvZ2FerHZKo1U1M-=991+Zg@mail.gmail.com>
On Wed, Jun 26, 2019 at 11:05:39AM -0400, Willem de Bruijn wrote:
> On Wed, Jun 26, 2019 at 6:54 AM Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > On Tue, Jun 25, 2019 at 06:30:08PM -0400, Willem de Bruijn wrote:
> > > > diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> > > > index a29d66da7394..a7ca6a003ebe 100644
> > > > --- a/net/packet/af_packet.c
> > > > +++ b/net/packet/af_packet.c
> > > > @@ -2401,6 +2401,9 @@ static void tpacket_destruct_skb(struct sk_buff *skb)
> > > >
> > > > ts = __packet_set_timestamp(po, ph, skb);
> > > > __packet_set_status(po, ph, TP_STATUS_AVAILABLE | ts);
> > > > +
> > > > + if (!packet_read_pending(&po->tx_ring))
> > > > + complete(&po->skb_completion);
> > > > }
> > > >
> > > > sock_wfree(skb);
> > > > @@ -2585,7 +2588,7 @@ static int tpacket_parse_header(struct packet_sock *po, void *frame,
> > > >
> > > > static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
> > > > {
> > > > - struct sk_buff *skb;
> > > > + struct sk_buff *skb = NULL;
> > > > struct net_device *dev;
> > > > struct virtio_net_hdr *vnet_hdr = NULL;
> > > > struct sockcm_cookie sockc;
> > > > @@ -2600,6 +2603,7 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
> > > > int len_sum = 0;
> > > > int status = TP_STATUS_AVAILABLE;
> > > > int hlen, tlen, copylen = 0;
> > > > + long timeo = 0;
> > > >
> > > > mutex_lock(&po->pg_vec_lock);
> > > >
> > > > @@ -2646,12 +2650,21 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
> > > > if ((size_max > dev->mtu + reserve + VLAN_HLEN) && !po->has_vnet_hdr)
> > > > size_max = dev->mtu + reserve + VLAN_HLEN;
> > > >
> > > > + reinit_completion(&po->skb_completion);
> > > > +
> > > > do {
> > > > ph = packet_current_frame(po, &po->tx_ring,
> > > > TP_STATUS_SEND_REQUEST);
> > > > if (unlikely(ph == NULL)) {
> > > > - if (need_wait && need_resched())
> > > > - schedule();
> > > > + if (need_wait && skb) {
> > > > + timeo = sock_sndtimeo(&po->sk, msg->msg_flags & MSG_DONTWAIT);
> > > > + timeo = wait_for_completion_interruptible_timeout(&po->skb_completion, timeo);
> > >
> > > This looks really nice.
> > >
> > > But isn't it still susceptible to the race where tpacket_destruct_skb
> > > is called in between po->xmit and this
> > > wait_for_completion_interruptible_timeout?
> > >
> > Thats not an issue, since the complete is only gated on packet_read_pending
> > reaching 0 in tpacket_destuct_skb. Previously it was gated on my
> > wait_on_complete flag being non-zero, so we had to set that prior to calling
> > po->xmit, or the complete call might never get made, resulting in a hang. Now,
> > we will always call complete, and the completion api allows for arbitrary
> > ordering of complete/wait_for_complete (since its internal done variable gets
> > incremented), making a call to wait_for_complete effectively a fall through if
> > complete gets called first.
>
> Perfect! I was not aware that it handles that internally. Hadn't read
> do_wait_for_common closely before.
>
> > There is an odd path here though. If an application calls sendmsg on a packet
> > socket here with MSG_DONTWAIT set, then need_wait will be zero, and we will
> > eventually exit this loop without ever having called wait_for_complete, but
> > tpacket_destruct_skb will still have called complete when all the frames
> > complete transmission. In and of itself, thats fine, but it leave the
> > completion structure in a state where its done variable will have been
> > incremented at least once (specifically it will be set to N, where N is the
> > number of frames transmitted during the call where MSG_DONTWAIT is set). If the
> > application then calls sendmsg on this socket with MSG_DONTWAIT clear, we will
> > call wait_for_complete, but immediately return from it (due to the previously
> > made calls to complete). I've corrected this however, but adding that call to
> > reinit_completion prior to the loop entry, so that we are always guaranteed to
> > have the completion variable set properly to wait for only the frames being sent
> > in this particular instance of the sendmsg call.
>
> Yep, understood.
>
> >
> > > The test for skb is shorthand for packet_read_pending != 0, right?
> > >
> > Sort of. gating on skb guarantees for us that we have sent at least one frame
> > in this call to tpacket_snd. If we didn't do that, then it would be possible
> > for an application to call sendmsg without setting any frames in the buffer to
> > TP_STATUS_SEND_REQUEST, which would cause us to wait for a completion without
> > having sent any frames, meaning we would block waiting for an event
> > (tpacket_destruct_skb), that will never happen. The check for skb ensures that
> > tpacket_snd_skb will get called, and that we will get a wakeup from a call to
> > wait_for_complete. It does suggest that packet_read_pending != 0, but thats not
> > guaranteed, because tpacket_destruct_skb may already have been called (see the
> > above explination regarding ordering of complete/wait_for_complete).
>
> But the inverse is true: if gating sleeping on packet_read_pending,
> the process only ever waits if a packet is still to be acknowledged.
> Then both the wait and wake clearly depend on the same state.
>
> Either way works, I think. So this is definitely fine.
>
Yeah, we could do that. Its basically a pick your poison situation, in the case
you stipulate, we could gate the wait_on_complete on read_pending being
non-zero, but if a frame frees quickly and decrements the pending count, we
still leave the loop with a completion struct that needs to be reset. Either
way we have to re-init the completion. And as for calling wait_on_complete when
we don't have to, your proposal does solve that prolbem but requires that we
call packet_read_pending an extra time for iteration on every loop.
Packet_read_pending accumulates the sum of all the per-cpu pointer pending
counts (which is a separate problem, I'm not sure why we're using per-cpu
counters there). Regardless, I looked at that and (anecdotally), decided that
periodically calling wait_for_complete which takes a spin lock would be more
performant than accessing a per-cpu variable on each available cpu every
iteration of the loop (based on the comments at the bottom of the loop).
> One possible refinement would be to keep po->wait_on_complete (but
> rename as po->wake_om_complete), set it before entering the loop and
> clear it before function return (both within the pg_vec_lock critical
> section). And test that in tpacket_destruct_skb to avoid calling
> complete if MSG_DONTWAIT. But I don't think it's worth the complexity.
>
I agree, we could use a socket variable to communicate to tpacket_destruct_skb
that we need to call complete, in conjunction with the pending count, but I
don't think the added complexity buys us anything.
> One rare edge case is a MSG_DONTWAIT send followed by a !MSG_DONTWAIT.
> It is then possible for a tpacket_destruct_skb to be run as a result
> from the first call, during the second call, after the call to
> reinit_completion. That would cause the next wait to return before
> *its* packets have been sent. But due to the packet_read_pending test
> in the while () condition it will loop again and return to wait. So that's fine.
>
yup, exactly.
> Thanks for bearing with me.
>
> Reviewed-by: Willem de Bruijn <willemb@google.com>
>
^ permalink raw reply
* INFO: rcu detected stall in ext4_write_checks
From: syzbot @ 2019-06-26 17:27 UTC (permalink / raw)
To: adilger.kernel, davem, eladr, idosch, jiri, john.stultz,
linux-ext4, linux-kernel, netdev, syzkaller-bugs, tglx, tytso
Hello,
syzbot found the following crash on:
HEAD commit: abf02e29 Merge tag 'pm-5.2-rc6' of git://git.kernel.org/pu..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1435aaf6a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=e5c77f8090a3b96b
dashboard link: https://syzkaller.appspot.com/bug?extid=4bfbbf28a2e50ab07368
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11234c41a00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15d7f026a00000
The bug was bisected to:
commit 0c81ea5db25986fb2a704105db454a790c59709c
Author: Elad Raz <eladr@mellanox.com>
Date: Fri Oct 28 19:35:58 2016 +0000
mlxsw: core: Add port type (Eth/IB) set API
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10393a89a00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=12393a89a00000
console output: https://syzkaller.appspot.com/x/log.txt?x=14393a89a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4bfbbf28a2e50ab07368@syzkaller.appspotmail.com
Fixes: 0c81ea5db259 ("mlxsw: core: Add port type (Eth/IB) set API")
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
(detected by 0, t=10502 jiffies, g=8969, q=26)
rcu: All QSes seen, last rcu_preempt kthread activity 10503
(4295056736-4295046233), jiffies_till_next_fqs=1, root ->qsmask 0x0
syz-executor778 R running task 26464 9577 9576 0x00004000
Call Trace:
<IRQ>
sched_show_task kernel/sched/core.c:5286 [inline]
sched_show_task.cold+0x291/0x2fc kernel/sched/core.c:5261
print_other_cpu_stall kernel/rcu/tree_stall.h:410 [inline]
check_cpu_stall kernel/rcu/tree_stall.h:536 [inline]
rcu_pending kernel/rcu/tree.c:2625 [inline]
rcu_sched_clock_irq.cold+0xaaf/0xbfd kernel/rcu/tree.c:2161
update_process_times+0x32/0x80 kernel/time/timer.c:1639
tick_sched_handle+0xa2/0x190 kernel/time/tick-sched.c:167
tick_sched_timer+0x47/0x130 kernel/time/tick-sched.c:1298
__run_hrtimer kernel/time/hrtimer.c:1389 [inline]
__hrtimer_run_queues+0x33b/0xdd0 kernel/time/hrtimer.c:1451
hrtimer_interrupt+0x314/0x770 kernel/time/hrtimer.c:1509
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1041 [inline]
smp_apic_timer_interrupt+0x111/0x550 arch/x86/kernel/apic/apic.c:1066
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:806
</IRQ>
RIP: 0010:ext4_write_checks+0x1/0x260 fs/ext4/file.c:161
Code: 61 fa ff ff e8 e0 3c 53 ff 55 48 89 e5 41 54 49 89 fc e8 f2 0a 81 ff
4c 89 e7 31 f6 e8 98 f9 ff ff 41 5c 5d c3 0f 1f 40 00 55 <48> 89 e5 41 56
41 55 49 89 f5 41 54 53 48 89 fb e8 ca 0a 81 ff 48
RSP: 0018:ffff888093a97640 EFLAGS: 00000293 ORIG_RAX: ffffffffffffff13
RAX: ffff88809901c100 RBX: ffff888093a977d8 RCX: ffffffff81efcb42
RDX: 0000000000000000 RSI: ffff888093a97a08 RDI: ffff888093a977d8
RBP: ffff888093a97768 R08: ffff88809901c100 R09: ffff88809901c9c8
R10: ffff88809901c9a8 R11: ffff88809901c100 R12: 0000000000000001
R13: ffff8880995df4f0 R14: ffff888093a97740 R15: 0000000000000000
call_write_iter include/linux/fs.h:1872 [inline]
do_iter_readv_writev+0x5f8/0x8f0 fs/read_write.c:693
do_iter_write fs/read_write.c:970 [inline]
do_iter_write+0x184/0x610 fs/read_write.c:951
vfs_iter_write+0x77/0xb0 fs/read_write.c:983
iter_file_splice_write+0x65c/0xbd0 fs/splice.c:746
do_splice_from fs/splice.c:848 [inline]
direct_splice_actor+0x123/0x190 fs/splice.c:1020
splice_direct_to_actor+0x366/0x970 fs/splice.c:975
do_splice_direct+0x1da/0x2a0 fs/splice.c:1063
do_sendfile+0x597/0xd00 fs/read_write.c:1464
__do_sys_sendfile64 fs/read_write.c:1519 [inline]
__se_sys_sendfile64 fs/read_write.c:1511 [inline]
__x64_sys_sendfile64+0x15a/0x220 fs/read_write.c:1511
do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4417c9
Code: e8 7c e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 bb 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffce5c38198 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 00007ffce5c38340 RCX: 00000000004417c9
RDX: 0000000020000000 RSI: 0000000000000003 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 00008080fffffffe R11: 0000000000000246 R12: 0000000000000000
R13: 00000000004024a0 R14: 0000000000000000 R15: 0000000000000000
rcu: rcu_preempt kthread starved for 10549 jiffies! g8969 f0x2
RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
rcu: RCU grace-period kthread stack dump:
rcu_preempt R running task 29056 10 2 0x80004000
Call Trace:
context_switch kernel/sched/core.c:2818 [inline]
__schedule+0x7cb/0x1560 kernel/sched/core.c:3445
schedule+0xa8/0x260 kernel/sched/core.c:3509
schedule_timeout+0x486/0xc50 kernel/time/timer.c:1807
rcu_gp_fqs_loop kernel/rcu/tree.c:1589 [inline]
rcu_gp_kthread+0x9b2/0x18b0 kernel/rcu/tree.c:1746
kthread+0x354/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH net v2] ipv4: reset rt_iif for recirculated mcast/bcast out pkts
From: David Ahern @ 2019-06-26 17:28 UTC (permalink / raw)
To: Stephen Suryaputra, netdev
In-Reply-To: <20190626062116.4319-1-ssuryaextr@gmail.com>
On 6/26/19 12:21 AM, Stephen Suryaputra wrote:
> Multicast or broadcast egress packets have rt_iif set to the oif. These
> packets might be recirculated back as input and lookup to the raw
> sockets may fail because they are bound to the incoming interface
> (skb_iif). If rt_iif is not zero, during the lookup, inet_iif() function
> returns rt_iif instead of skb_iif. Hence, the lookup fails.
>
> v2: Make it non vrf specific (David Ahern). Reword the changelog to
> reflect it.
> Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
> ---
> include/net/route.h | 1 +
> net/ipv4/ip_output.c | 12 ++++++++++++
> net/ipv4/route.c | 33 +++++++++++++++++++++++++++++++++
> 3 files changed, 46 insertions(+)
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Johannes Berg @ 2019-06-26 17:45 UTC (permalink / raw)
To: Alex Elder, Arnd Bergmann
Cc: Dan Williams, Subash Abhinov Kasiviswanathan, abhishek.esse,
Ben Chan, Bjorn Andersson, cpratapa, David Miller, DTML,
Eric Caruso, evgreen, Ilias Apalodimas, Linux ARM, linux-arm-msm,
Linux Kernel Mailing List, linux-soc, Networking, syadagir
In-Reply-To: <edea19ef-f225-bdcd-f394-77e326d1d3ad@linaro.org>
On Wed, 2019-06-26 at 08:39 -0500, Alex Elder wrote:
> > However, to also reply to Alex: I don't know exactly how IPA works, but
> > for the Intel modem at least you can't fundamentally have two drivers
> > for different parts of the functionality, since it's just a single piece
> > of hardware and you need to allocate hardware resources from a common
> > pool etc. So you cannot split the driver into "Intel modem control
> > channel driver" and "Intel modem data channel driver". In fact, it's
> > just a single "struct device" on the PCIe bus that you can bind to, and
> > only one driver can bind at a time.
>
> Interesting. So a single modem driver needs to implement
> *all* of the features/functions? Like GPS or data log or
> whatever, all needs to share the same struct device?
> Or does what you're describing apply to a subset of the
> modem's functionality? Or something else?
Well, what is even the "implement the functions"? I mean, as kernel
drivers we're really just in the business of providing communication
channels to those functions. E.g. if you have a GNSS/GPS device, you
might just have another TTY channel with NMEA data coming out, or
something like that, right?
But from a kernel POV yes, I don't see how you could create multiple
function drivers for something behind the same PCIe device (unless it
actually appeared as multiple virtual functions or such, like the bigger
ethernet NICs, but it doesn't).
But this points out to me that I was actually not quite accurate when I
spoke about struct device before in the USB context with function
drivers, but I have to do some research before I can correct myself
correctly.
> > So, IOW, I'm not sure I see how you'd split that up. I guess you could
> > if you actually do something like the "rmnet" model, and I suppose
> > you're free to do that for IPA if you like, but I tend to think that's
> > actually a burden, not a win since you just get more complex code that
> > needs to interact with more pieces. A single driver for a single
> > hardware that knows about the few types of channels seems simpler to me.
> >
> > > - to answer Johannes question, my understanding is that the interface
> > > between kernel and firmware/hardware for IPA has a single 'struct
> > > device' that is used for both the data and the control channels,
> > > rather than having a data channel and an independent control device,
> > > so this falls into the same category as the Intel one (please correct
> > > me on that)
>
> I don't think that's quite right, but it might be partially
> right. There is a single device representing IPA, but the
> picture is a little more complicated.
>
> The IPA hardware is actually something that sits *between* the
> AP and the modem. It implements one form of communication
> pathway (IP data), but there are others (including QMI, which
> presents a network-like interface but it's actually implemented
> via clever use of shared memory and interrupts).
OK.
Well, I guess this then might eventually become a bit of a hybrid - you
eventually want one WWAN device to represent it all to userspace, but
might actually have multiple devices with different drivers (from the
kernel POV)?
But this is more like all the USB devices work. I just have to figure
out how to correctly tie them together - "struct device" may or may not
be right? I need to check how this functions.
I guess for something where you have DT (like you allude to elsewhere)
you could just capture all this in DT by having some phandle link or
something?
> What we're talking about here is WWAN/modem management more
> generally though. It *sounds* like the Intel modem is
> more like a single device, which requires a single driver,
> that seems to implement a bunch of distinct functions.
Yes.
> On this I'm not very knowledgeable but for Qualcomm there is
> user space code that is in charge of overall management of
> the modem. It implements what I think you're calling control
> functions, negotiating with the modem to allow new data channels
> to be created. Normally the IPA driver would provide information
> to user space about available resources, but would only make a
> communication pathway available when requested.
Right.
> > Are the control channels to IPA are actually also tunnelled over the
> > rmnet protocol? And even if they are, perhaps they have a different
> > hardware queue or so? That'd be the case for Intel - different hardware
> > queue, same (or at least similar) protocol spoken for the DMA hardware
> > itself, but different contents of the messages obviously.
>
> I want to be careful talking about "control" but for IPA it comes
> from user space. For the purpose of getting initial code upstream,
> all of that control functionality (which was IOCTL based) has been
> removed, and a fixed configuration is assumed.
But something that's ioctl based is just one form of "control" pathway.
I was thinking of the AT or MBIM commands "control" channel. And then
ioctls are likely something that terminates in the *driver*, right? I
mean, the driver wouldn't get an ioctl and actually talk AT commands to
the device ...
But yes, the various control planes are confusing, we need to
disentangle that. I tried over in the other email by layering where the
control terminates.
johannes
^ permalink raw reply
* Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Johannes Berg @ 2019-06-26 17:48 UTC (permalink / raw)
To: Arnd Bergmann, Alex Elder
Cc: Dan Williams, Subash Abhinov Kasiviswanathan, abhishek.esse,
Ben Chan, Bjorn Andersson, cpratapa, David Miller, DTML,
Eric Caruso, evgreen, Ilias Apalodimas, Linux ARM, linux-arm-msm,
Linux Kernel Mailing List, linux-soc, Networking, syadagir
In-Reply-To: <CAK8P3a3wHe_6ay8P+F9Vo=k19P5fifs6RWozxFF5nGYYjO_=Xw@mail.gmail.com>
On Wed, 2019-06-26 at 15:58 +0200, Arnd Bergmann wrote:
>
> > The IPA hardware is actually something that sits *between* the
> > AP and the modem. It implements one form of communication
> > pathway (IP data), but there are others (including QMI, which
> > presents a network-like interface but it's actually implemented
> > via clever use of shared memory and interrupts).
>
> Can you clarify how QMI fits in here? Do you mean one has to
> talk to both IPA and QMI to use the modem, or are these two
> alternative implementations for the same basic purpose?
I'm not going to comment on QMI specifically, because my understanding
might well be wrong, and any response to your question will likely
correct my understanding :-)
(Thus, you should probably also ignore everything I ever said about QMI)
> My previous understanding was that from the hardware perspective
> there is only one control interface, which is for IPA. Part of this
> is abstracted to user space with ioctl commands to the IPA driver,
> and then one must set up rmnet to match these by configuring
> an rmnet device over netlink messages from user space, but
> rmnet does not have a control protocol with the hardware.
Right so this is why I say it's confusing when we just talk about
"control interface" or "path".
I see multiple layers of control
* hardware control, which you mention here. This might be things like
"enable/disable aggregation on an rmnet channel" etc. I guess this
type of thing would have been implemented with ioctls? Not the
aggregation specifically, but things that affect how you set up the
hardware.
* modem control, which we conflate, but can be like AT commands or
MBIM. From the kernel driver POV, this is actually just another
channel it provides for userspace to talk to the modem.
johannes
^ permalink raw reply
* Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Johannes Berg @ 2019-06-26 17:55 UTC (permalink / raw)
To: Alex Elder, Dan Williams, Arnd Bergmann
Cc: Subash Abhinov Kasiviswanathan, abhishek.esse, Ben Chan,
Bjorn Andersson, cpratapa, David Miller, DTML, Eric Caruso,
evgreen, Ilias Apalodimas, Linux ARM, linux-arm-msm,
Linux Kernel Mailing List, linux-soc, Networking, syadagir
In-Reply-To: <0f5c0332-6894-2fdd-fd25-7af9a21b445b@linaro.org>
On Wed, 2019-06-26 at 08:36 -0500, Alex Elder wrote:
>
> We need to identify the existence of a WWAN device (which is I
> guess--typically? always?--a modem). Perhaps that can be
> discovered in some cases but I think it means a node described
> by Device Tree.
Yeah, perhaps that's something you could do. I'm not sure though. For
one, for USB devices, obviously it isn't :-) And even for IPA you might
want to support existing DTs I guess.
> So you're saying you have a single Ethernet driver, and it can
> drive an Ethernet device connected to a WWAN, or not connected
> to a WWAN, without any changes. The only distinction is that
> if the device is part of a WWAN it needs to register with the
> WWAN framework. Is that right?
That's what I'm thinking, and I believe (mostly from discussions with
Dan) that this actually exists.
> > > So maybe:
> > > - Hardware probe detects a WWAN device
> > > - The drivers that detect the WWAN device register it with the
> > > WWAN core code.
> > > - A control channel is instantiated at/before the time the WWAN
> > > device is registered
> > > - Something in user space should manage the bring-up of any
> > > other things on the WWAN device thereafter
> >
> > But those things need to actually get connected first :-)
>
> What I meant is that the registering with the "WWAN core code"
> is what does that "connecting." The WWAN code has the information
> about what got registered. But as I said above, this WWAN device
> needs to be identified, and I think (at least for IPA) that will
> require something in Device Tree. That will "connect" them.
>
> Or I might be misunderstanding your point.
No, I think we're mostly agreeing, just thinking about different
scenarios. I think for IPA you don't really *need* anything in the DT
though - as soon as the IPA driver is loaded you know for sure you
actually have a modem there, and the IPA driver presumably loads based
on some existing probing (didn't look at it now).
Now, I don't know how the QMI channel to the modem is set up, so of
course you'd want a way of identifying that the two channels (IPA and
QMI) go to the same device and link them together in the WWAN framework.
> > If userspace actually had the ability to create (data) channels, then it
> > would have the ability to also remove them. Right now, this may or may
> > not be supported by the drivers that act together to form the interfaces
> > to a WWAN device.
>
> I think this (user space control) needs to be an option, but
> it doesn't have to be the only way.
Agree.
johannes
^ permalink raw reply
* Re: WWAN Controller Framework (was IPA [PATCH v2 00/17])
From: Johannes Berg @ 2019-06-26 17:58 UTC (permalink / raw)
To: Alex Elder, davem, arnd, bjorn.andersson, ilias.apalodimas,
Dan Williams
Cc: evgreen, benchan, ejcaruso, cpratapa, syadagir, subashab,
abhishek.esse, netdev, devicetree, linux-kernel, linux-soc,
linux-arm-kernel, linux-arm-msm
In-Reply-To: <25bb0936-686c-101b-c5a4-474ed37536aa@linaro.org>
On Wed, 2019-06-26 at 08:40 -0500, Alex Elder wrote:
> > I think here we need to be more careful. I don't know how you want to
> > call it, but we actually have multiple levels of control here.
>
> I completely agree with you. From what I understand there exists
> a control channel (or even more than one?) that serves a very
> specific purpose in modem management. The main reason I mention
> the WWAN control function is that someone (maybe you) indicated
> that a control channel automatically gets created.
It may or may not, right. I just bought a cheap used USB modem, and it
just comes with two USB TTY channels, so I guess for data it does PPP on
top of that. But those channels are created automatically once you
connect the device to the system.
OTOH, for something like the Intel modem, we might well decide not to
create *any* channels on driver load, since you have the option of using
AT commands or MBIM (but I believe both at the same time wouldn't really
make sense, if even allowed).
> > This ... depends a bit on how you exactly define a physical channel
> > here. Is that, to you, the PCIe/USB link? In that case, yes, obviously
> > you have only one physical channel for each WWAN unit.
>
> I think that was what I was trying to capture. There exists
> one or more "physical" communication paths between the AP
> and WWAN unit/modem. And while one path *could* carry just
> one type of traffic, it could also carry multiple logical
> channels of traffic by multiplexing.
Right.
(What I wasn't aware is that QMI is actually a different physical path.
I thought it was just a protocol multiplexed on top of the same IPA
physical path).
> I don't think I have any argument with this. I'm going to try to
> put together something that goes beyond what I wrote in this message,
> to try to capture what I think we agree on in a sort of loose design
> document.
Awesome, thanks a lot!
johannes
^ 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