* [PATCH net-next v1] net: stmmac: initialize the reset delay array
From: Martin Blumenstingl @ 2019-06-18 20:39 UTC (permalink / raw)
To: netdev, davem
Cc: linux-kernel, joabreu, alexandre.torgue, peppe.cavallaro, khilman,
Martin Blumenstingl
Commit ce4ab73ab0c27c ("net: stmmac: drop the reset delays from struct
stmmac_mdio_bus_data") moved the reset delay array from struct
stmmac_mdio_bus_data to a stack variable.
The values from the array inside struct stmmac_mdio_bus_data were
previously initialized to 0 because the struct was allocated using
devm_kzalloc(). The array on the stack has to be initialized
explicitly, else we might be reading garbage values.
Initialize all reset delays to 0 to ensure that the values are 0 if the
"snps,reset-delays-us" property is not defined.
This fixes booting at least two boards (MIPS pistachio marduk and ARM
sun8i H2+ Orange Pi Zero). These are hanging during boot when
initializing the stmmac Ethernet controller (as found by Kernel CI).
Both have in common that they don't define the "snps,reset-delays-us"
property.
Fixes: ce4ab73ab0c27c ("net: stmmac: drop the reset delays from struct stmmac_mdio_bus_data")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
On my Amlogic boards the delay values are 0 even without this patch.
I may have been lucky with my kernel build that I'm not triggering
the same fault as Kernel CI found on the two boards mentioned here: [0]
Please feel free to squash this into net-next commit ce4ab73ab0c27c.
[0] https://lore.kernel.org/netdev/7hr27qdedo.fsf@baylibre.com/T/#u
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index da310de06bf6..18cadf0b0d66 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -241,7 +241,7 @@ int stmmac_mdio_reset(struct mii_bus *bus)
#ifdef CONFIG_OF
if (priv->device->of_node) {
struct gpio_desc *reset_gpio;
- u32 delays[3];
+ u32 delays[3] = { 0, 0, 0 };
reset_gpio = devm_gpiod_get_optional(priv->device,
"snps,reset",
--
2.22.0
^ permalink raw reply related
* Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Johannes Berg @ 2019-06-18 20:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alex Elder, abhishek.esse, Ben Chan, Bjorn Andersson, cpratapa,
David Miller, Dan Williams, DTML, Eric Caruso, evgreen,
Ilias Apalodimas, Linux ARM, linux-arm-msm,
Linux Kernel Mailing List, linux-soc, Networking,
Subash Abhinov Kasiviswanathan, syadagir
In-Reply-To: <CAK8P3a1FeUQR3pgoQxHoRK05JGORyR+TFATVQiijLWtFKTv6OQ@mail.gmail.com>
On Tue, 2019-06-18 at 21:59 +0200, Arnd Bergmann wrote:
>
> From my understanding, the ioctl interface would create the lower
> netdev after talking to the firmware, and then user space would use
> the rmnet interface to create a matching upper-level device for that.
> This is an artifact of the strong separation of ipa and rmnet in the
> code.
Huh. But if rmnet has muxing, and IPA supports that, why would you ever
need multiple lower netdevs?
> > > > The software bridging [...]
>
> My understanding for this was that the idea is to use it for
> connecting bridging between distinct hardware devices behind
> ipa: if IPA drives both a USB-ether gadget and the 5G modem,
> you can use to talk to Linux running rmnet, but you can also
> use rmnet to provide fast usb tethering to 5g and bypass the
> rest of the network stack. That again may have been a wrong
> guess on my part.
Hmm. Interesting. It didn't really look to me like that, but I'm really
getting lost in the code. Anyway, it seems weird, because then you'd
just bridge the upper netdev with the other ethernet and don't need
special logic? And I don't see how the ethernet headers would work with
this now.
> ipa definitely has multiple hardware queues, and the Alex'
> driver does implement the data path on those, just not the
> configuration to enable them.
OK, but perhaps you don't actually have enough to use one for each
session?
> Guessing once more, I suspect the the XON/XOFF flow control
> was a workaround for the fact that rmnet and ipa have separate
> queues. The hardware channel on IPA may fill up, but user space
> talks to rmnet and still add more frames to it because it doesn't
> know IPA is busy.
>
> Another possible explanation would be that this is actually
> forwarding state from the base station to tell the driver to
> stop sending data over the air.
Yeah, but if you actually have a hardware queue per upper netdev then
you don't really need this - you just stop the netdev queue when the
hardware queue is full, and you have flow control automatically.
So I really don't see any reason to have these messages going back and
forth unless you plan to have multiple sessions muxed on a single
hardware queue.
And really, if you don't mux multiple sessions onto a single hardware
queue, you don't need a mux header either, so it all adds up :-)
johannes
^ permalink raw reply
* Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Arnd Bergmann @ 2019-06-18 20:33 UTC (permalink / raw)
To: Johannes Berg
Cc: Alex Elder, 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: <97cbfb3723607c95d78e25785262ae7b0acdb11c.camel@sipsolutions.net>
On Tue, Jun 18, 2019 at 10:15 PM Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2019-06-18 at 22:09 +0200, Arnd Bergmann wrote:
> > > One is the whole multi-function device, where a single WWAN device is
> > > composed of channels offered by actually different drivers, e.g. for a
> > > typical USB device you might have something like cdc_ether and the
> > > usb_wwan TTY driver. In this way, we need to "compose" the WWAN device
> > > similarly, e.g. by using the underlying USB device "struct device"
> > > pointer to tie it together.
> > >
> > > The other is something like IPA or the Intel modem driver, where the
> > > device is actually a single (e.g. PCIe) device and just has a single
> > > driver, but that single driver offers different channels.
> >
> > I would hope we can simplify this to expect only the second model,
> > where you have a 'struct device' corresponding to hardware and the
> > driver for it creates one wwan_device that user space talks to.
>
> I'm not sure.
>
> Fundamentally, we have drivers in Linux for the ethernet part, for the
> TTY part, and for whatever other part might be in a given USB multi-
> function device.
>
> > Clearly the multi-function device hardware has to be handled somehow,
> > but it would seem much cleaner in the long run to do that using
> > a special workaround rather than putting this into the core interface.
>
> I don't think it really makes the core interface much more complex or
> difficult though, and it feels easier than writing a completely
> different USB driver yet again for all these devices?
>
> As far as I understand from Dan, sometimes they really are no different
> from a generic USB TTY and a generic USB ethernet, except you know that
> if those show up together it's a modem.
>
> > E.g. have a driver that lets you create a wwan_device by passing
> > netdev and a tty chardev into a configuration interface, and from that
> > point on use the generic wwan abstraction.
>
> Yeah, but where do you hang that driver? Maybe the TTY function is
> actually a WWAN specific USB driver, but the ethernet is something
> generic that can also work with pure ethernet USB devices, and it's
> difficult to figure out how to tie those together. The modules could
> load in completely different order, or even the ethernet module could
> load but the TTY one doesn't because it's not configured, or vice versa.
That was more or less my point: The current drivers exist, but don't
lean themselves to fitting into a new framework, so maybe the best
answer is not to try fitting them.
To clarify: I'm not suggesting to write new USB drivers for these at all,
but instead keep three parts that are completely unaware of each other
a) a regular netdevice driver
b) a regular tty driver
c) the new wwan subsystem that expects a device to be created
from a hardware driver but knows nothing of a) and b)
To connect these together, we need one glue driver that implements
the wwan_device and talks to a) and b) as the hardware. There are
many ways to do that. One way would be to add a tty ldisc driver.
A small user space helper opens the chardev, sets the ldisc
and then uses an ldisc specific ioctl command to create a wwan
device by passing an identifier of the netdevice and then exits.
From that point on, you have a wwan device like any other.
Arnd
^ permalink raw reply
* Re: [PATCH v4 00/28] Convert files to ReST - part 1
From: Mauro Carvalho Chehab @ 2019-06-18 14:14 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Palmer Dabbelt, Albert Ou, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Greentime Hu,
Vincent Chen, linux-riscv, netdev, bpf
In-Reply-To: <20190614143640.40ee353a@lwn.net>
Em Fri, 14 Jun 2019 14:36:40 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Wed, 12 Jun 2019 14:52:36 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > This is mostly a rebase of the /33 series v3 I sent, on the top of the latest
> > linux-next (next-20190612).
> >
> > Changes from v3:
> >
> > - dropped cpufreq conversion - documents are too outdated;
> > - infiniband patch is not here anymore - as it should be merged via RDMA;
> > - s390 patches were already merged;
> > - Dropped Geert as Maintainer from fb/framebuffer.rst, as per his request;
> > - Did a minor editorial change at popwerpc/cxl.rst per Andrew Donellan
> > request;
> > - Added acks/reviews;
> > - trivial rebase fixups.
>
> So I had to pull docs-next forward to -rc4, but then I was able to apply
> this set except for parts 5, 6, 14, 18, and 19.
Patch 5 went via Cgroups tree;
Patch 18 went via power tree;
Patch 6 is obsolete, as the cgroups-v1 CBQ chapter was removed;
So, what's left from this series are patches 14 and 19.
I have a rebased version of them on the top of linux-next
on my working tree. Perhaps we should try to push those two late
during the merge window.
> Some progress made, but
> this is somewhat painful work...
Yeah, a change like that is not easy.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH 7/8] net: ethernet: ixp4xx: Add DT bindings
From: Rob Herring @ 2019-06-18 20:22 UTC (permalink / raw)
To: Linus Walleij
Cc: netdev, David S . Miller, Krzysztof Halasa,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CACRpkdbkwTtS2ofpxkZLERW-b+4=d7m9qiPXGT+iMemn9zZE1A@mail.gmail.com>
On Tue, Jun 18, 2019 at 1:44 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Fri, May 24, 2019 at 9:41 PM Rob Herring <robh@kernel.org> wrote:
>
> > > + reg:
> > > + maxItems: 1
> > > + description: Ethernet MMIO address range
> > > +
> > > + queue-rx:
> > > + $ref: '/schemas/types.yaml#/definitions/phandle-array'
> > > + maxItems: 1
> >
> > This doesn't actually do what you think it is doing. A $ref plus
> > additional constraints need to be under an 'allOf' list.
> >
> > > + description: phandle to the RX queue on the NPE
> >
> > But this is a phandle plus 1 cell, right?
> >
> > - allOf:
> > - $ref: '/schemas/types.yaml#/definitions/phandle-array'
> > - items:
> > - items:
> > - description: phandle to the RX queue on the NPE
> > - description: whatever the cell contains
> > enum: [ 1, 2, 3, 4 ] # any constraints you can put on the cell
> >
> > This implicitly says you have 1 of a phandle + 1 cell.
> >
> > I need to add this to example-schema.yaml...
>
> I just can't get this right :(
>
> I have this:
>
> queue-rx:
> - allOf:
Properties take a schema/object/dict or boolean. You are making
queue-rx a list. Drop the '-'.
> - $ref: '/schemas/types.yaml#/definitions/phandle-array'
> - items:
> - items:
> - description: phandle to the RX queue on the NPE
> - description: index of the NPE engine RX queue to use
> enum: [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]
>
> I get this from dt_binding_check:
>
> CHKDT Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml
> Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml:
> properties:queue-rx: [{'allOf': [{'$ref':
> '/schemas/types.yaml#/definitions/phandle-array'}, {'items':
> [{'items': [{'description': 'phandle to the RX queue on the NPE'},
> {'description': 'index of the NPE engine RX queue to use', 'enum': [0,
> 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]}]}]}]}] is not of type 'object',
> 'boolean'
> make[3]: *** [../Documentation/devicetree/bindings/Makefile:12:
> Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.example.dts]
> Error 1
>
> Hm .... I just can't figure out what this recursive parsing thingie means...
> I tried to update the pip3 repo but no cigar.
What do you mean pip didn't work?
Rob
^ permalink raw reply
* Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Johannes Berg @ 2019-06-18 20:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alex Elder, 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: <CAK8P3a3ksrFTo2+dLB+doLeY+kPP7rYxv2O7BwvjYgK2cwCTuQ@mail.gmail.com>
On Tue, 2019-06-18 at 22:09 +0200, Arnd Bergmann wrote:
>
> > One is the whole multi-function device, where a single WWAN device is
> > composed of channels offered by actually different drivers, e.g. for a
> > typical USB device you might have something like cdc_ether and the
> > usb_wwan TTY driver. In this way, we need to "compose" the WWAN device
> > similarly, e.g. by using the underlying USB device "struct device"
> > pointer to tie it together.
> >
> > The other is something like IPA or the Intel modem driver, where the
> > device is actually a single (e.g. PCIe) device and just has a single
> > driver, but that single driver offers different channels.
>
> I would hope we can simplify this to expect only the second model,
> where you have a 'struct device' corresponding to hardware and the
> driver for it creates one wwan_device that user space talks to.
I'm not sure.
Fundamentally, we have drivers in Linux for the ethernet part, for the
TTY part, and for whatever other part might be in a given USB multi-
function device.
> Clearly the multi-function device hardware has to be handled somehow,
> but it would seem much cleaner in the long run to do that using
> a special workaround rather than putting this into the core interface.
I don't think it really makes the core interface much more complex or
difficult though, and it feels easier than writing a completely
different USB driver yet again for all these devices?
As far as I understand from Dan, sometimes they really are no different
from a generic USB TTY and a generic USB ethernet, except you know that
if those show up together it's a modem.
> E.g. have a driver that lets you create a wwan_device by passing
> netdev and a tty chardev into a configuration interface, and from that
> point on use the generic wwan abstraction.
Yeah, but where do you hang that driver? Maybe the TTY function is
actually a WWAN specific USB driver, but the ethernet is something
generic that can also work with pure ethernet USB devices, and it's
difficult to figure out how to tie those together. The modules could
load in completely different order, or even the ethernet module could
load but the TTY one doesn't because it's not configured, or vice versa.
> > Now, it's not clear to me where IPA actually falls, because so far we've
> > been talking about the IPA driver only as providing *netdevs*, not any
> > control channels, so I'm not actually sure where the control channel is.
>
> The IPA driver today only handles the data path, because Alex removed
> the control channel. IPA is the driver that needs to talk to the hardware,
> both for data and control when finished. rmnet is a pure software construct
> that also contains both a data and control side and is designed to be
> independent of the lower hardware.
I'd actually be interested in what the control path should be like.
Is it also muxed on QMAP in the same way?
johannes
^ permalink raw reply
* Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Arnd Bergmann @ 2019-06-18 20:09 UTC (permalink / raw)
To: Johannes Berg
Cc: Alex Elder, 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: <abdfc6b3a9981bcdef40f85f5442a425ce109010.camel@sipsolutions.net>
On Tue, Jun 18, 2019 at 9:03 PM Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2019-06-18 at 08:45 -0500, Alex Elder wrote:
> Really there are two possible ways (and they intersect to some extent).
>
> One is the whole multi-function device, where a single WWAN device is
> composed of channels offered by actually different drivers, e.g. for a
> typical USB device you might have something like cdc_ether and the
> usb_wwan TTY driver. In this way, we need to "compose" the WWAN device
> similarly, e.g. by using the underlying USB device "struct device"
> pointer to tie it together.
>
> The other is something like IPA or the Intel modem driver, where the
> device is actually a single (e.g. PCIe) device and just has a single
> driver, but that single driver offers different channels.
I would hope we can simplify this to expect only the second model,
where you have a 'struct device' corresponding to hardware and the
driver for it creates one wwan_device that user space talks to.
Clearly the multi-function device hardware has to be handled somehow,
but it would seem much cleaner in the long run to do that using
a special workaround rather than putting this into the core interface.
E.g. have a driver that lets you create a wwan_device by passing
netdev and a tty chardev into a configuration interface, and from that
point on use the generic wwan abstraction.
> Now, it's not clear to me where IPA actually falls, because so far we've
> been talking about the IPA driver only as providing *netdevs*, not any
> control channels, so I'm not actually sure where the control channel is.
The IPA driver today only handles the data path, because Alex removed
the control channel. IPA is the driver that needs to talk to the hardware,
both for data and control when finished. rmnet is a pure software construct
that also contains both a data and control side and is designed to be
independent of the lower hardware.
Arnd
^ permalink raw reply
* Re: [PATCH] [v2] net/mlx5e: reduce stack usage in mlx5_eswitch_termtbl_create
From: Saeed Mahameed @ 2019-06-18 20:05 UTC (permalink / raw)
To: arnd@arndb.de, leon@kernel.org
Cc: linux-rdma@vger.kernel.org, Or Gerlitz, Oz Shlomo, Paul Blakey,
Mark Bloch, Maor Gottlieb, linux-kernel@vger.kernel.org,
davem@davemloft.net, Eli Britstein, netdev@vger.kernel.org
In-Reply-To: <20190618111621.3030135-1-arnd@arndb.de>
On Tue, 2019-06-18 at 13:15 +0200, Arnd Bergmann wrote:
> Putting an empty 'mlx5_flow_spec' structure on the stack is a bit
> wasteful and causes a warning on 32-bit architectures when building
> with clang -fsanitize-coverage:
>
> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c:
> In function 'mlx5_eswitch_termtbl_create':
> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c:90
> :1: error: the frame size of 1032 bytes is larger than 1024 bytes [-
> Werror=frame-larger-than=]
>
> Since the structure is never written to, we can statically allocate
> it to avoid the stack usage. To be on the safe side, mark all
> subsequent function arguments that we pass it into as 'const'
> as well.
>
> Fixes: 10caabdaad5a ("net/mlx5e: Use termination table for VLAN push
> actions")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
> Acked-by: Mark Bloch <markb@mellanox.com>
Applied to net-next-mlx5 and will be submitted to net-next soon.
Thanks,
Saeed.
^ permalink raw reply
* Re: 4.19: udpgso_bench_tx: setsockopt zerocopy: Unknown error 524
From: Willem de Bruijn @ 2019-06-18 20:04 UTC (permalink / raw)
To: Greg KH
Cc: David Miller, Naresh Kamboju, Network Development, LKML,
open list:KERNEL SELFTEST FRAMEWORK, Fred Klassen
In-Reply-To: <CA+FuTSdrphico4044QTD_-8VbanFFJx0FJuH+vVMfuHqbphkjw@mail.gmail.com>
On Tue, Jun 18, 2019 at 2:59 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Tue, Jun 18, 2019 at 1:39 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Jun 18, 2019 at 01:27:14PM -0400, Willem de Bruijn wrote:
> > > On Tue, Jun 18, 2019 at 1:15 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Tue, Jun 18, 2019 at 09:47:59AM -0700, David Miller wrote:
> > > > > From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> > > > > Date: Tue, 18 Jun 2019 12:37:33 -0400
> > > > >
> > > > > > Specific to the above test, I can add a check command testing
> > > > > > setsockopt SO_ZEROCOPY return value. AFAIK kselftest has no explicit
> > > > > > way to denote "skipped", so this would just return "pass". Sounds a
> > > > > > bit fragile, passing success when a feature is absent.
> > > > >
> > > > > Especially since the feature might be absent because the 'config'
> > > > > template forgot to include a necessary Kconfig option.
> > > >
> > > > That is what the "skip" response is for, don't return "pass" if the
> > > > feature just isn't present. That lets people run tests on systems
> > > > without the config option enabled as you say, or on systems without the
> > > > needed userspace tools present.
> > >
> > > I was not aware that kselftest had this feature.
> > >
> > > But it appears that exit code KSFT_SKIP (4) will achieve this. Okay,
> > > I'll send a patch and will keep that in mind for future tests.
> >
> > Wonderful, thanks for doing that!
>
> One complication: an exit code works for a single test, but here
> multiple test variants are run from a single shell script.
>
> I see that in similar such cases that use the test harness
> (ksft_test_result_skip) the overall test returns success as long as
> all individual cases return either success or skip.
>
> I think it's preferable to return KSFT_SKIP if any of the cases did so
> (and none returned an error). I'll do that unless anyone objects.
http://patchwork.ozlabs.org/patch/1118309/
The shell script scaffolding can perhaps be reused for other similar tests.
^ permalink raw reply
* [PATCH net-next] selftests/net: make udpgso_bench skip unsupported testcases
From: Willem de Bruijn @ 2019-06-18 20:03 UTC (permalink / raw)
To: netdev; +Cc: davem, gregkh, naresh.kamboju, linux-kselftest, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
Kselftest can be run against older kernels. Instead of failing hard
when a feature is unsupported, return the KSFT_SKIP exit code.
Specifically, do not fail hard on missing udp zerocopy.
The udp gso bench test runs multiple test cases from a single script.
Fail if any case fails, else return skip if any test is skipped.
Link: https://lore.kernel.org/lkml/20190618171516.GA17547@kroah.com/
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
tools/testing/selftests/net/udpgso_bench.sh | 75 +++++++++++--------
tools/testing/selftests/net/udpgso_bench_tx.c | 18 ++++-
2 files changed, 59 insertions(+), 34 deletions(-)
diff --git a/tools/testing/selftests/net/udpgso_bench.sh b/tools/testing/selftests/net/udpgso_bench.sh
index 4df1cd8d69d2..80b5d352702e 100755
--- a/tools/testing/selftests/net/udpgso_bench.sh
+++ b/tools/testing/selftests/net/udpgso_bench.sh
@@ -3,9 +3,47 @@
#
# Run a series of udpgso benchmarks
-GREEN='\033[0;92m'
-RED='\033[0;31m'
-NC='\033[0m' # No Color
+readonly GREEN='\033[0;92m'
+readonly YELLOW='\033[0;33m'
+readonly RED='\033[0;31m'
+readonly NC='\033[0m' # No Color
+
+readonly KSFT_PASS=0
+readonly KSFT_FAIL=1
+readonly KSFT_SKIP=4
+
+num_pass=0
+num_err=0
+num_skip=0
+
+kselftest_test_exitcode() {
+ local -r exitcode=$1
+
+ if [[ ${exitcode} -eq ${KSFT_PASS} ]]; then
+ num_pass=$(( $num_pass + 1 ))
+ elif [[ ${exitcode} -eq ${KSFT_SKIP} ]]; then
+ num_skip=$(( $num_skip + 1 ))
+ else
+ num_err=$(( $num_err + 1 ))
+ fi
+}
+
+kselftest_exit() {
+ echo -e "$(basename $0): PASS=${num_pass} SKIP=${num_skip} FAIL=${num_err}"
+
+ if [[ $num_err -ne 0 ]]; then
+ echo -e "$(basename $0): ${RED}FAIL${NC}"
+ exit ${KSFT_FAIL}
+ fi
+
+ if [[ $num_skip -ne 0 ]]; then
+ echo -e "$(basename $0): ${YELLOW}SKIP${NC}"
+ exit ${KSFT_SKIP}
+ fi
+
+ echo -e "$(basename $0): ${GREEN}PASS${NC}"
+ exit ${KSFT_PASS}
+}
wake_children() {
local -r jobs="$(jobs -p)"
@@ -29,93 +67,66 @@ run_in_netns() {
local -r args=$@
./in_netns.sh $0 __subprocess ${args}
+ kselftest_test_exitcode $?
}
run_udp() {
local -r args=$@
- local errors=0
echo "udp"
run_in_netns ${args}
- errors=$(( $errors + $? ))
echo "udp gso"
run_in_netns ${args} -S 0
- errors=$(( $errors + $? ))
echo "udp gso zerocopy"
run_in_netns ${args} -S 0 -z
- errors=$(( $errors + $? ))
echo "udp gso timestamp"
run_in_netns ${args} -S 0 -T
- errors=$(( $errors + $? ))
echo "udp gso zerocopy audit"
run_in_netns ${args} -S 0 -z -a
- errors=$(( $errors + $? ))
echo "udp gso timestamp audit"
run_in_netns ${args} -S 0 -T -a
- errors=$(( $errors + $? ))
echo "udp gso zerocopy timestamp audit"
run_in_netns ${args} -S 0 -T -z -a
- errors=$(( $errors + $? ))
-
- return $errors
}
run_tcp() {
local -r args=$@
- local errors=0
echo "tcp"
run_in_netns ${args} -t
- errors=$(( $errors + $? ))
echo "tcp zerocopy"
run_in_netns ${args} -t -z
- errors=$(( $errors + $? ))
# excluding for now because test fails intermittently
# add -P option to include poll() to reduce possibility of lost messages
#echo "tcp zerocopy audit"
#run_in_netns ${args} -t -z -P -a
- #errors=$(( $errors + $? ))
-
- return $errors
}
run_all() {
local -r core_args="-l 3"
local -r ipv4_args="${core_args} -4 -D 127.0.0.1"
local -r ipv6_args="${core_args} -6 -D ::1"
- local errors=0
echo "ipv4"
run_tcp "${ipv4_args}"
- errors=$(( $errors + $? ))
run_udp "${ipv4_args}"
- errors=$(( $errors + $? ))
echo "ipv6"
run_tcp "${ipv4_args}"
- errors=$(( $errors + $? ))
run_udp "${ipv6_args}"
- errors=$(( $errors + $? ))
-
- return $errors
}
if [[ $# -eq 0 ]]; then
run_all
- if [ $? -ne 0 ]; then
- echo -e "$(basename $0): ${RED}FAIL${NC}"
- exit 1
- fi
-
- echo -e "$(basename $0): ${GREEN}PASS${NC}"
+ kselftest_exit
elif [[ $1 == "__subprocess" ]]; then
shift
run_one $@
diff --git a/tools/testing/selftests/net/udpgso_bench_tx.c b/tools/testing/selftests/net/udpgso_bench_tx.c
index dfa83ad57206..ada99496634a 100644
--- a/tools/testing/selftests/net/udpgso_bench_tx.c
+++ b/tools/testing/selftests/net/udpgso_bench_tx.c
@@ -25,6 +25,8 @@
#include <sys/types.h>
#include <unistd.h>
+#include "../kselftest.h"
+
#ifndef ETH_MAX_MTU
#define ETH_MAX_MTU 0xFFFFU
#endif
@@ -45,6 +47,10 @@
#define MSG_ZEROCOPY 0x4000000
#endif
+#ifndef ENOTSUPP
+#define ENOTSUPP 524
+#endif
+
#define NUM_PKT 100
static bool cfg_cache_trash;
@@ -603,7 +609,7 @@ int main(int argc, char **argv)
{
unsigned long num_msgs, num_sends;
unsigned long tnow, treport, tstop;
- int fd, i, val;
+ int fd, i, val, ret;
parse_opts(argc, argv);
@@ -623,8 +629,16 @@ int main(int argc, char **argv)
if (cfg_zerocopy) {
val = 1;
- if (setsockopt(fd, SOL_SOCKET, SO_ZEROCOPY, &val, sizeof(val)))
+
+ ret = setsockopt(fd, SOL_SOCKET, SO_ZEROCOPY,
+ &val, sizeof(val));
+ if (ret) {
+ if (errno == ENOPROTOOPT || errno == ENOTSUPP) {
+ fprintf(stderr, "SO_ZEROCOPY not supported");
+ exit(KSFT_SKIP);
+ }
error(1, errno, "setsockopt zerocopy");
+ }
}
if (cfg_connected &&
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Arnd Bergmann @ 2019-06-18 19:59 UTC (permalink / raw)
To: Johannes Berg
Cc: Alex Elder, abhishek.esse, Ben Chan, Bjorn Andersson, cpratapa,
David Miller, Dan Williams, DTML, Eric Caruso, evgreen,
Ilias Apalodimas, Linux ARM, linux-arm-msm,
Linux Kernel Mailing List, linux-soc, Networking,
Subash Abhinov Kasiviswanathan, syadagir
In-Reply-To: <b23a83c18055470c5308fcd1eed018056371fc1d.camel@sipsolutions.net>
On Tue, Jun 18, 2019 at 9:14 PM Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2019-06-18 at 08:16 -0500, Alex Elder wrote:
> > On 6/17/19 6:28 AM, Johannes Berg wrote:
> > So getting back to your question, the IPA in its current form only
> > has a single "multiplexed" channel carried over the connection
> > between the AP and modem. Previously (and in the future) there
> > was a way to add or remove channels.
>
> What would those channels do?
>
> I've not really been very clear with the differentiation between a
> channel and what's multiplexed inside of the channel.
>
> Using the terminology you defined in your other mail, are you saying
> that IPA (originally) allowed multiple *connections* to the device, or
> is there basically just one connection, with multiple (QMAP-muxed)
> *channels* on top of it?
>
> If the latter, why did IPA need ioctls, rather than rmnet?
From my understanding, the ioctl interface would create the lower
netdev after talking to the firmware, and then user space would use
the rmnet interface to create a matching upper-level device for that.
This is an artifact of the strong separation of ipa and rmnet in the
code.
> > > The software bridging is very questionable to start with, I'd advocate
> > > not supporting that at all but adding tracepoints or similar if needed
> > > for debugging instead.
> >
> > To be honest I don't understand the connection between software
> > bridging and debugging, but that's OK.
>
> It's a mess. Basically, AFAICT, the only use for the rmnet bridging is
> in fact debugging. What it does, again AFAICT, is mirror out all the
> rmnet packets to the bridge if you attach it to a bridge, so that then
> you can attach another netdev to the bridge and forward all the rmnet
> packets to another system for debugging.
>
> It's a very weird way of doing this, IMHO.
My understanding for this was that the idea is to use it for
connecting bridging between distinct hardware devices behind
ipa: if IPA drives both a USB-ether gadget and the 5G modem,
you can use to talk to Linux running rmnet, but you can also
use rmnet to provide fast usb tethering to 5g and bypass the
rest of the network stack. That again may have been a wrong
guess on my part.
> > I believe the only QMAP commands are for doing essentially
> > XON/XOFF flow control on a single channel. In the course of
> > the e-mail discussion in the past few weeks I've come to see
> > why that would be necessary.
>
> It does make sense, because you only have a single hardware (DMA)
> channel in these cases, so you implement flow control in software on
> top.
>
> (As I said before, the Intel modem uses different hardware channels for
> different sessions, so doesn't need something like this - the hardware
> ring just fills up and there's your flow control)
ipa definitely has multiple hardware queues, and the Alex'
driver does implement the data path on those, just not the
configuration to enable them.
Guessing once more, I suspect the the XON/XOFF flow control
was a workaround for the fact that rmnet and ipa have separate
queues. The hardware channel on IPA may fill up, but user space
talks to rmnet and still add more frames to it because it doesn't
know IPA is busy.
Another possible explanation would be that this is actually
forwarding state from the base station to tell the driver to
stop sending data over the air.
Arnd
^ permalink raw reply
* Re: [PATCH v2 6/6] net: macb: parameter added to cadence ethernet controller DT binding
From: Florian Fainelli @ 2019-06-18 19:47 UTC (permalink / raw)
To: Parshuram Thombare, andrew, nicolas.ferre, davem
Cc: netdev, hkallweit1, linux-kernel, rafalc, aniljoy, piotrs
In-Reply-To: <1560883527-10591-1-git-send-email-pthombar@cadence.com>
On 6/18/19 11:45 AM, Parshuram Thombare wrote:
> New parameters added to Cadence ethernet controller DT binding
> for USXGMII interface.
Please don't resubmit individual patches as replies to your previous
ones, re-submitting the entire patch series, see this netdev-FAQ section
for details:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/netdev-FAQ.rst#n134
>
> Signed-off-by: Parshuram Thombare <pthombar@cadence.com>
> ---
> Documentation/devicetree/bindings/net/macb.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
> index 9c5e94482b5f..b80d58ed1650 100644
> --- a/Documentation/devicetree/bindings/net/macb.txt
> +++ b/Documentation/devicetree/bindings/net/macb.txt
> @@ -25,6 +25,9 @@ Required properties:
> Optional elements: 'rx_clk' applies to cdns,zynqmp-gem
> Optional elements: 'tsu_clk'
> - clocks: Phandles to input clocks.
> +- serdes-rate External serdes rate.Mandatory for USXGMII mode.
> + 5 - 5G
> + 10 - 10G
There should be an unit specifier in that property, something like:
serdes-rate-gbps
can't we somehow automatically detect that?
>
> The MAC address will be determined using the optional properties
> defined in ethernet.txt.
>
--
Florian
^ permalink raw reply
* Re: [PATCH 7/8] net: ethernet: ixp4xx: Add DT bindings
From: Linus Walleij @ 2019-06-18 19:44 UTC (permalink / raw)
To: Rob Herring
Cc: netdev, David S . Miller, Krzysztof Halasa,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CAL_Jsq+bZsJ+SBiJa2hzXU9RkTNBhDk_Uv_Fk6V6DqRGh-xPRg@mail.gmail.com>
On Fri, May 24, 2019 at 9:41 PM Rob Herring <robh@kernel.org> wrote:
> > + reg:
> > + maxItems: 1
> > + description: Ethernet MMIO address range
> > +
> > + queue-rx:
> > + $ref: '/schemas/types.yaml#/definitions/phandle-array'
> > + maxItems: 1
>
> This doesn't actually do what you think it is doing. A $ref plus
> additional constraints need to be under an 'allOf' list.
>
> > + description: phandle to the RX queue on the NPE
>
> But this is a phandle plus 1 cell, right?
>
> - allOf:
> - $ref: '/schemas/types.yaml#/definitions/phandle-array'
> - items:
> - items:
> - description: phandle to the RX queue on the NPE
> - description: whatever the cell contains
> enum: [ 1, 2, 3, 4 ] # any constraints you can put on the cell
>
> This implicitly says you have 1 of a phandle + 1 cell.
>
> I need to add this to example-schema.yaml...
I just can't get this right :(
I have this:
queue-rx:
- allOf:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
- items:
- items:
- description: phandle to the RX queue on the NPE
- description: index of the NPE engine RX queue to use
enum: [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]
I get this from dt_binding_check:
CHKDT Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml
Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml:
properties:queue-rx: [{'allOf': [{'$ref':
'/schemas/types.yaml#/definitions/phandle-array'}, {'items':
[{'items': [{'description': 'phandle to the RX queue on the NPE'},
{'description': 'index of the NPE engine RX queue to use', 'enum': [0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 10]}]}]}]}] is not of type 'object',
'boolean'
make[3]: *** [../Documentation/devicetree/bindings/Makefile:12:
Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.example.dts]
Error 1
Hm .... I just can't figure out what this recursive parsing thingie means...
I tried to update the pip3 repo but no cigar.
Any hints?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic
From: Jon Hunter @ 2019-06-18 19:44 UTC (permalink / raw)
To: Jose Abreu, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Cc: Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue, Russell King, Andrew Lunn, Florian Fainelli,
Heiner Kallweit, linux-tegra
In-Reply-To: <d96f8bea-f7ef-82ae-01ba-9c97aec0ee38@nvidia.com>
On 18/06/2019 16:20, Jon Hunter wrote:
>
> On 18/06/2019 11:18, Jon Hunter wrote:
>>
>> On 18/06/2019 10:46, Jose Abreu wrote:
>>> From: Jon Hunter <jonathanh@nvidia.com>
>>>
>>>> I am not certain but I don't believe so. We are using a static IP address
>>>> and mounting the root file-system via NFS when we see this ...
>>>
>>> Can you please add a call to napi_synchronize() before every
>>> napi_disable() calls, like this:
>>>
>>> if (queue < rx_queues_cnt) {
>>> napi_synchronize(&ch->rx_napi);
>>> napi_disable(&ch->rx_napi);
>>> }
>>>
>>> if (queue < tx_queues_cnt) {
>>> napi_synchronize(&ch->tx_napi);
>>> napi_disable(&ch->tx_napi);
>>> }
>>>
>>> [ I can send you a patch if you prefer ]
>>
>> Yes I can try this and for completeness you mean ...
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index 4ca46289a742..d4a12cb64d8e 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -146,10 +146,15 @@ static void stmmac_disable_all_queues(struct stmmac_priv *priv)
>> for (queue = 0; queue < maxq; queue++) {
>> struct stmmac_channel *ch = &priv->channel[queue];
>>
>> - if (queue < rx_queues_cnt)
>> + if (queue < rx_queues_cnt) {
>> + napi_synchronize(&ch->rx_napi);
>> napi_disable(&ch->rx_napi);
>> - if (queue < tx_queues_cnt)
>> + }
>> +
>> + if (queue < tx_queues_cnt) {
>> + napi_synchronize(&ch->tx_napi);
>> napi_disable(&ch->tx_napi);
>> + }
>> }
>> }
>
> So good news and bad news ...
>
> The good news is that the above change does fix the initial crash
> I am seeing. However, even with this change applied on top of
> -next, it is still dying somewhere else and so there appears to
> be a second issue.
Further testing has shown that actually this does NOT resolve the issue
and I am still seeing the crash. Sorry for the false-positive.
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Johannes Berg @ 2019-06-18 19:22 UTC (permalink / raw)
To: Alex Elder, Arnd Bergmann
Cc: abhishek.esse, Ben Chan, Bjorn Andersson, cpratapa, David Miller,
Dan Williams, DTML, Eric Caruso, evgreen, Ilias Apalodimas,
Linux ARM, linux-arm-msm, Linux Kernel Mailing List, linux-soc,
Networking, Subash Abhinov Kasiviswanathan, syadagir
In-Reply-To: <31c2c94c-c6d3-595b-c138-faa54d0bfc00@linaro.org>
On Tue, 2019-06-18 at 09:00 -0500, Alex Elder wrote:
> Deaggregation is a connection property, not a channel property.
That'd make sense, yes.
> And it looks like that's exactly how it's used in the rmnet
> driver.
Yeah, I think you're right. I got confused by the whole use of "port"
there, but it seems like "port" actually refers to the underlying
netdev.
Which is really strange too, btw, because you configure the "port" to
agg/non-agg when you add a new channel to it ... So it seems like it's
part of the channel configuration, when it's not!
Anyway, I think for now we could probably live with not having this
configurable for the IPA driver, and if it *does* need to be
configurable, it seems like it should be a driver configuration, not a
channel configuration - so something like a debugfs hook if you really
just need to play with it for performance testing, or a module
parameter, or something else?
Or even, in the WWAN framework, a knob that we provide there for the
WWAN device, rather than for the (newly created) channel.
> The hardware is capable of aggregating QMAP packets
> arriving on a connection into a single buffer, so this provides
> a way of requesting it do that.
>
> > > #define RMNET_FLAGS_INGRESS_MAP_COMMANDS (1U << 1)
> >
> > Similar here? If you have flow control you probably want to use it?
>
> I agree with that, though perhaps there are cases where it
> is pointless, or can't be supported, so one might want to
> simply *not* implement/advertise the feature. I don't know.
Sure, but then that's likely something the driver would need to know,
not necessarily userspace?
johannes
^ permalink raw reply
* Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Johannes Berg @ 2019-06-18 19:14 UTC (permalink / raw)
To: Alex Elder, Arnd Bergmann
Cc: abhishek.esse, Ben Chan, Bjorn Andersson, cpratapa, David Miller,
Dan Williams, DTML, Eric Caruso, evgreen, Ilias Apalodimas,
Linux ARM, linux-arm-msm, Linux Kernel Mailing List, linux-soc,
Networking, Subash Abhinov Kasiviswanathan, syadagir
In-Reply-To: <b3686626-e2d8-bc9c-6dd0-9ebb137715af@linaro.org>
On Tue, 2019-06-18 at 08:16 -0500, Alex Elder wrote:
> On 6/17/19 6:28 AM, Johannes Berg wrote:
> > On Tue, 2019-06-11 at 13:56 +0200, Arnd Bergmann wrote:
> > > On Tue, Jun 11, 2019 at 10:12 AM Johannes Berg
> > > <johannes@sipsolutions.net> wrote:
> > >
> > > > > As I've made clear before, my work on this has been focused on the IPA transport,
> > > > > and some of this higher-level LTE architecture is new to me. But it
> > > > > seems pretty clear that an abstracted WWAN subsystem is a good plan,
> > > > > because these devices represent a superset of what a "normal" netdev
> > > > > implements.
> > > >
> > > > I'm not sure I'd actually call it a superset. By themselves, these
> > > > netdevs are actually completely useless to the network stack, AFAICT.
> > > > Therefore, the overlap with netdevs you can really use with the network
> > > > stack is pretty small?
> > >
> > > I think Alex meant the concept of having a type of netdev with a generic
> > > user space interface for wwan and similar to a wlan device, as I understood
> > > you had suggested as well, as opposed to a stacked device as in
> > > rmnet or those drivers it seems to be modeled after (vlan, ip tunnel, ...)/.
>
> Yes, that's pretty much what I meant by "superset." We still need
> netdev functionality (though not between rmnet and ipa). And it sounds
> like we're talking about a better framework for managing the related
> WWAN devices that represent logical modem connections. We're discussing
> more than one spot in the networking stack though, so I can see why
> "superset" wasn't the right word.
Right, ok, gotcha. I was focused (here at least) much more on the
netdevs, rather than the whole "superset" of functionality :-)
> > I guess. It is indeed currently modelled after the stacked devices, but
> > those regular netdevs are inherently useful by themselves, you don't
> > *have* to tunnel or use VLANs after all.
> >
> > With rmnet, the underlying netdev *isn't* useful by itself, because
> > you're always forced to have the stacked rmnet device on top.
>
> Well I had mentioned earlier that I thought IPA could present just
> a single non-rmnet interface that could be used "directly" (i.e.,
> without rmnet). But that would be a sort of hard-wired thing, and
> would not be part of the general WWAN framework under discussion.
Oh, I guess I didn't see that (got to the thread late), but is that
actually useful? It doesn't seem very useful to me since you can't
actually do anything there.
> Here's a little background.
That's great to have :-) Let me read and comment/ask questions.
> The IPA driver was very large, and in an effort to have an initial driver
> that was more easily accepted upstream, it was carved down to support
> a single, very simple use case. It supports only a single channel for
> carrying network data, and does not expose any of the IPA's other
> capabilities like filtering and routing (and multiplexing).
Ok. But it *does* use (or even require using) rmnet, so it has multiple
channels in a sense, no?
> Originally the IPA code had an IOCTL interface for adding and removing
> multiplexed channel IDs, but the simplified use case expected only one
> channel to be used.
What did those channels do? Create different netdevs? Something else?
> IOCTLs had to be removed to make the code acceptable
> for upstream, and again to simplify things, we went with a hard-wired
> configuration, with a single channel with an assumed set of features
> in use (TCP offload, basically). Once upstream, we planned to add back
> features in layers, including adding a netlink interface to control
> things like managing multiplexed channels.
Right, ok.
> The overall design assumed that the IPA connection between the modem
> and AP was carrying QMAP protocol though. And the rmnet driver is
> designed to parse and handle that, so for the design I started with
> the use of the rmnet driver made sense: it is a shim layer that takes
> care of rmnet multiplexing and aggregation (and checksum offload).
Sure, I can't really disagree. It's just that we have an ongoing
discussion separately about whether or not rmnet really makes sense
itself, mostly starting from our interest in supporting the Intel modem,
and realizing that we have like 5 or 6 different driver-specific
interfaces of doing the same thing.
> So getting back to your question, the IPA in its current form only
> has a single "multiplexed" channel carried over the connection
> between the AP and modem. Previously (and in the future) there
> was a way to add or remove channels.
What would those channels do?
I've not really been very clear with the differentiation between a
channel and what's multiplexed inside of the channel.
Using the terminology you defined in your other mail, are you saying
that IPA (originally) allowed multiple *connections* to the device, or
is there basically just one connection, with multiple (QMAP-muxed)
*channels* on top of it?
If the latter, why did IPA need ioctls, rather than rmnet?
> > The software bridging is very questionable to start with, I'd advocate
> > not supporting that at all but adding tracepoints or similar if needed
> > for debugging instead.
>
> To be honest I don't understand the connection between software
> bridging and debugging, but that's OK.
It's a mess. Basically, AFAICT, the only use for the rmnet bridging is
in fact debugging. What it does, again AFAICT, is mirror out all the
rmnet packets to the bridge if you attach it to a bridge, so that then
you can attach another netdev to the bridge and forward all the rmnet
packets to another system for debugging.
It's a very weird way of doing this, IMHO.
> I'm a fan of tracepoints
> and have always intended to make use of them in the IPA driver.
:-)
> The hardware can aggregate multiple packets received from the
> modem into a single buffer, which the rmnet driver is then able
> to deaggregate.
Right, I gathered that much, but I'm not really sure I see why userspace
would even be allowed to control this? Either the device is doing it or
not, but the driver is going to have to cope either way?
> This feature is supposed to help performance
> but I've always been a little skeptical because it also comes
> at a cost. This is used as a flag in an rmnet (QMAP) header,
> which to me seems a little odd. (There should be a distinction
> between flags needed in a message header and flags that represent
> properties of a connection or channel.)
I'm not going to comment on the QMAP protocol, I know nothing about it
:-)
> I believe the only QMAP commands are for doing essentially
> XON/XOFF flow control on a single channel. In the course of
> the e-mail discussion in the past few weeks I've come to see
> why that would be necessary.
It does make sense, because you only have a single hardware (DMA)
channel in these cases, so you implement flow control in software on
top.
(As I said before, the Intel modem uses different hardware channels for
different sessions, so doesn't need something like this - the hardware
ring just fills up and there's your flow control)
> The checksum offload is done differently, depending on whether
> it's ingress (download from modem) or egress. For egress,
> a header is inserted that describes what the hardware should
> checksum and where it should place the result. For ingress,
> the hardware appends a trailer that contains information
> about the computed checksum values. The rmnet driver is
> currently responsible for inserting the header and parsing
> the trailer.
Sure, makes sense, but again - if you can negotiate with the modem on
whether it's going to do RX CSUM offload, you can tell it with ethtool
(assuming you do have a netdev per channel, I guess), and for TX CSUM
you can just have the header or not depending on whether you want it and
the modem is capable of it.
> I'm probably missing something, but I think the checksum
> offload could be handled by the IPA driver rather than
> rmnet. It seems to be an add-on that is completely
> independent of the multiplexing and aggregation capabilities
> that QMAP provides.
Agree.
> > > > If true though, then I think this would be the killer argument *in
> > > > favour* of *not* merging this - because that would mean we *don't* have
> > > > to actually keep the rmnet API around for all foreseeable future.
>
> This is because it's a user space API? If so I now understand
> what you mean.
Yes.
> As Arnd said (below) this is designed in the way out-of-tree code
> works and expects. I don't want to advocate for breaking that,
> but if a general model that supports what's required can be used,
> I'll adapt the IPA code to suit that.
>
> My goal continues to be getting a baseline IPA driver accepted
> upstream as soon as possible, so I can then start building on
> that foundation.
Yeah. My goal is actually the same, but for the Intel driver, but I
don't have much code yet (it's being cleaned up now) :-)
johannes
^ permalink raw reply
* Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Johannes Berg @ 2019-06-18 19:03 UTC (permalink / raw)
To: Alex Elder, Arnd Bergmann, Dan Williams
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: <d533b708-c97a-710d-1138-3ae79107f209@linaro.org>
On Tue, 2019-06-18 at 08:45 -0500, Alex Elder wrote:
> If it had a well-defined way of creating new channels to be
> multiplexed over the connection to the modem, the IPA driver
> (rather than the rmnet driver) could present network interfaces
> for each and perform the multiplexing.
Right. That's what I was thinking of.
I actually expect this to fare much better going forward with 5G around
the corner, since you'll want to eventually take advantage of multi-
queue TX or RSS for RX, queue size control and what not, as speeds
increase.
Because of these things I think the whole "layered netdev" approach is
actually *wrong* rather than just inconvenient.
In particular, in the Intel driver, you're going to have multiple
hardware queues, one for each ongoing session. This means that
multiplexing it over a layered netdev like rmnet or something like VLAN
(which some driver does too) actually prevents us from doing this
properly - it means we need to implement ndo_select_queue() and multiple
queues on the underlying netdev etc., and then we no longer have the
ability to use actual multi-queue. It becomes messy very very quickly.
> As I think Arnd
> suggested, this could at least partially be done with library
> code (to be shared with other "back-end" interfaces) rather
> than using a layered driver. This applies to aggregation,
> channel flow control, and checksum offload as well.
Right.
> But I'm only familiar with IPA; I don't know whether the above
> statements make any sense for other "back-end" drivers.
I think they do, in different ways. Intel probably wouldn't have a
library - there isn't actually much of a MUX header because there are
different hardware queues for the different sessions.
> This is great. The start of a more concrete discussion of the
> pieces that are missing...
:-)
I think I said before - it should be pretty easy to mold some code
around the API I proposed there and have something reasonably functional
soon.
> That would be nice. I believe you're saying that (in my case)
> the IPA driver creates and owns the netdevices.
Yes.
> But I think the IPA driver would register with the WWAN core as
> a "provider," and then the WWAN core would subsequently request
> that it instantiate netdevices to represent channels on demand
> (rather than registering them).
Yeah, I guess you could call it that way.
Really there are two possible ways (and they intersect to some extent).
One is the whole multi-function device, where a single WWAN device is
composed of channels offered by actually different drivers, e.g. for a
typical USB device you might have something like cdc_ether and the
usb_wwan TTY driver. In this way, we need to "compose" the WWAN device
similarly, e.g. by using the underlying USB device "struct device"
pointer to tie it together.
The other is something like IPA or the Intel modem driver, where the
device is actually a single (e.g. PCIe) device and just has a single
driver, but that single driver offers different channels.
Now, it's not clear to me where IPA actually falls, because so far we've
been talking about the IPA driver only as providing *netdevs*, not any
control channels, so I'm not actually sure where the control channel is.
For the Intel device, however, the control channel is definitely
provided by exactly the same driver as the data channels (netdevs).
"provider" is a good word, and in fact the Intel driver would also be a
provider for a GNSS channel (TBD how to represent, a tty?), one or
multiple debug/tracing channels, data channels (netdevs), AT command
channels (mbim, ...?) (again tbd how to represent, ttys?), etc.
What I showed in the header files I posted so far was the provider only
having "data channel" ops (create/remove a netdev) but for each channel
type we either want a new method there, or we just change the method to
be something like
int (*create_channel)(..., enum wwan_chan_type chan_type, ...);
and simply require that the channel is attached to the wwan device with
the representation-specific call (wwan_attach_netdev, wwan_attach_tty,
...).
This is a bit less comfortable because then it's difficult to know what
was actually created upon the request, so it's probably better to have
different methods for the different types of representations (like I had
- add_netdev, add_tty, ...).
Note also that I said "representation-specific", while passing a
"channel type", so for this we'd actually need a convention on what
channel type has what kind of representation, which again gets awkward.
Better to make it explicit.
(And even then, we might be able to let userspace have some control,
e.g. the driver might be able to create a debug channel as both a TTY or
something else)
johannes
^ permalink raw reply
* Re: [PATCH][next] net/mlx5: add missing void argument to function mlx5_devlink_alloc
From: Saeed Mahameed @ 2019-06-18 19:02 UTC (permalink / raw)
To: linux-rdma@vger.kernel.org, colin.king@canonical.com,
davem@davemloft.net, leon@kernel.org, netdev@vger.kernel.org
Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190618151510.18672-1-colin.king@canonical.com>
On Tue, 2019-06-18 at 16:15 +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Function mlx5_devlink_alloc is missing a void argument, add it
> to clean up the non-ANSI function declaration.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/devlink.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
> b/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
> index ed4202e883f0..1533c657220b 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
> @@ -37,7 +37,7 @@ static const struct devlink_ops mlx5_devlink_ops =
> {
> .flash_update = mlx5_devlink_flash_update,
> };
>
> -struct devlink *mlx5_devlink_alloc()
> +struct devlink *mlx5_devlink_alloc(void)
> {
> return devlink_alloc(&mlx5_devlink_ops, sizeof(struct
> mlx5_core_dev));
> }
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
Dave, this one can go to net-next.
Thanks,
Saeed.
^ permalink raw reply
* Re: [PATCH] net: mvpp2: cls: Add pmap to fs dump
From: Nick Desaulniers @ 2019-06-18 19:00 UTC (permalink / raw)
To: Nathan Huckleberry
Cc: David S. Miller, maxime.chevallier, netdev, LKML,
clang-built-linux
In-Reply-To: <20190618160910.62922-1-nhuck@google.com>
On Tue, Jun 18, 2019 at 9:09 AM 'Nathan Huckleberry' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
>
> There was an unused variable 'mvpp2_dbgfs_prs_pmap_fops'
> Added a usage consistent with other fops to dump pmap
> to userspace.
>
> Cc: clang-built-linux@googlegroups.com
> Link: https://github.com/ClangBuiltLinux/linux/issues/529
> Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Looks good to me based on Maxime's suggestion. Thanks for seeking
clarification and following up on the feedback.
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Nathan, you should use Suggested-by tags (liberally, IMO) when your
patch is based on feedback from others, in this case:
Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
> drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c
> index 0ee39ea47b6b..55947bc63cfd 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c
> @@ -566,6 +566,9 @@ static int mvpp2_dbgfs_prs_entry_init(struct dentry *parent,
> debugfs_create_file("hits", 0444, prs_entry_dir, entry,
> &mvpp2_dbgfs_prs_hits_fops);
>
> + ddebugfs_create_file("pmap", 0444, prs_entry_dir, entry,
> + &mvpp2_dbgfs_prs_pmap_fops);
> +
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: 4.19: udpgso_bench_tx: setsockopt zerocopy: Unknown error 524
From: Willem de Bruijn @ 2019-06-18 18:58 UTC (permalink / raw)
To: Greg KH
Cc: Willem de Bruijn, David Miller, Naresh Kamboju,
Network Development, LKML, open list:KERNEL SELFTEST FRAMEWORK,
Fred Klassen
In-Reply-To: <20190618173906.GB3649@kroah.com>
On Tue, Jun 18, 2019 at 1:39 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Jun 18, 2019 at 01:27:14PM -0400, Willem de Bruijn wrote:
> > On Tue, Jun 18, 2019 at 1:15 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, Jun 18, 2019 at 09:47:59AM -0700, David Miller wrote:
> > > > From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> > > > Date: Tue, 18 Jun 2019 12:37:33 -0400
> > > >
> > > > > Specific to the above test, I can add a check command testing
> > > > > setsockopt SO_ZEROCOPY return value. AFAIK kselftest has no explicit
> > > > > way to denote "skipped", so this would just return "pass". Sounds a
> > > > > bit fragile, passing success when a feature is absent.
> > > >
> > > > Especially since the feature might be absent because the 'config'
> > > > template forgot to include a necessary Kconfig option.
> > >
> > > That is what the "skip" response is for, don't return "pass" if the
> > > feature just isn't present. That lets people run tests on systems
> > > without the config option enabled as you say, or on systems without the
> > > needed userspace tools present.
> >
> > I was not aware that kselftest had this feature.
> >
> > But it appears that exit code KSFT_SKIP (4) will achieve this. Okay,
> > I'll send a patch and will keep that in mind for future tests.
>
> Wonderful, thanks for doing that!
One complication: an exit code works for a single test, but here
multiple test variants are run from a single shell script.
I see that in similar such cases that use the test harness
(ksft_test_result_skip) the overall test returns success as long as
all individual cases return either success or skip.
I think it's preferable to return KSFT_SKIP if any of the cases did so
(and none returned an error). I'll do that unless anyone objects.
^ permalink raw reply
* bonded active-backup ethernet-wifi drops packets
From: Brian J. Murrell @ 2019-06-18 18:57 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]
Hi.
I have an active-backup bonded connection on a 5.1.6 kernel where the
slaves are an Ethernet interface and a wifi interface. The goal is to
have network transparent (i.e. same and IP address on both interfaces)
interface which takes advantage of high-speed and low-latency when it
can be physically plugged into the wired network but have portability
when unplugged through WiFi.
It all works, mostly. :-/
I find that even when the primary interface, being the Ethernet
interface is plugged in and active, the bonded interface will drop
packets periodically.
If I down the bonded interface and plumb the Ethernet interface
directly, not as a slave of the bonded interface, no such packet
dropping occurs.
My measure of packet dropping, is by observing the output of "sudo ping
-f <ip_address>. In less than a few minutes even, on the bonded
interface, even with the Ethernet interface as the active slave, I will
have a long string of dots indicating pings that were never
replied. On the unbonded Ethernet interface, no dots, even when
measured over many days.
My bonding config:
$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: enp0s31f6 (primary_reselect always)
Currently Active Slave: enp0s31f6
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: enp0s31f6
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 0c:54:15:4a:b2:0d
Slave queue ID: 0
Slave Interface: wlp2s0
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 1
Permanent HW addr: 0c:54:15:4a:b2:0d
Slave queue ID: 0
Current interface config/stats:
$ ifconfig bond0
bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500
inet 10.75.22.245 netmask 255.255.255.0 broadcast 10.75.22.255
inet6 fe80::ee66:b8c9:d55:a28f prefixlen 64 scopeid 0x20<link>
inet6 2001:123:ab:123:d36d:5e5d:acc8:e9bc prefixlen 64 scopeid 0x0<global>
ether 0c:54:15:4a:b2:0d txqueuelen 1000 (Ethernet)
RX packets 1596206 bytes 165221404 (157.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1590552 bytes 162689350 (155.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Devices:
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-LM (rev 31)
02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)
Happy to provide any other useful information.
Any ideas why the dropping, only when using the bonded interface?
Cheers,
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC net-next 1/2] net: sched: refactor reinsert action
From: Jakub Kicinski @ 2019-06-18 18:57 UTC (permalink / raw)
To: Edward Cree
Cc: John Hurley, netdev, davem, fw, jhs, simon.horman, oss-drivers,
Paolo Abeni
In-Reply-To: <dbd77b82-5951-8512-bc9d-e47abd400be3@solarflare.com>
On Mon, 17 Jun 2019 19:43:53 +0100, Edward Cree wrote:
> On 14/06/2019 15:33, John Hurley wrote:
> > Instead of
> > returning TC_ACT_REINSERT, change the type to the new TC_ACT_CONSUMED
> > which tells the caller that the packet has been stolen by another process
> > and that no consume call is required.
> Possibly a dumb question, but why does this need a new CONSUMED rather
> than, say, taking an additional ref and returning TC_ACT_STOLEN?
Is it okay to reinsert a shared skb into the stack? In particular this
looks a little scary:
int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
gfp_t gfp_mask)
{
int i, osize = skb_end_offset(skb);
int size = osize + nhead + ntail;
long off;
u8 *data;
BUG_ON(nhead < 0);
BUG_ON(skb_shared(skb));
^^^^^^^^^^^^^^^^^^^^^^^^
Actually looking for Paolo's address to add him to CC I found that he
said at the time:
With ACT_SHOT caller/upper layer will free the skb, too. We will have
an use after free (from either the upper layer and the xmit device).
Similar issues with STOLEN, TRAP, etc.
In the past, Changli Gao attempted to avoid the clone incrementing the
skb usage count:
commit 210d6de78c5d7c785fc532556cea340e517955e1
Author: Changli Gao <xiaosuo@gmail.com>
Date: Thu Jun 24 16:25:12 2010 +0000
act_mirred: don't clone skb when skb isn't shared
but some/many device drivers expect an skb usage count of 1, and that
caused ooops and was revered.
:)
^ permalink raw reply
* [PATCH] net: hns3: Fix inconsistent indenting
From: Krzysztof Kozlowski @ 2019-06-18 18:54 UTC (permalink / raw)
To: Yisen Zhuang, Salil Mehta, David S. Miller, netdev, linux-kernel
Cc: Krzysztof Kozlowski
Fix wrong indentation of goto return.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 58633cdcdcfd..c3c79e92b1f7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3864,7 +3864,7 @@ static int hns3_client_init(struct hnae3_handle *handle)
ret = hns3_client_start(handle);
if (ret) {
dev_err(priv->dev, "hns3_client_start fail! ret=%d\n", ret);
- goto out_client_start;
+ goto out_client_start;
}
hns3_dcbnl_setup(handle);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH bpf-next v6 1/9] bpf: implement getsockopt and setsockopt hooks
From: Stanislav Fomichev @ 2019-06-18 18:53 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Stanislav Fomichev, Network Development, bpf, David S. Miller,
Alexei Starovoitov, Daniel Borkmann, Martin Lau
In-Reply-To: <CAADnVQ+kymi+zJww+PfPd4WWhvNA67ynGVTd7oj6jiU+XFeguQ@mail.gmail.com>
On 06/18, Alexei Starovoitov wrote:
> On Tue, Jun 18, 2019 at 11:09 AM Stanislav Fomichev <sdf@fomichev.me> wrote:
> >
> > On 06/18, Stanislav Fomichev wrote:
> > > On 06/18, Alexei Starovoitov wrote:
> > > > On Mon, Jun 17, 2019 at 11:01:01AM -0700, Stanislav Fomichev wrote:
> > > > > Implement new BPF_PROG_TYPE_CGROUP_SOCKOPT program type and
> > > > > BPF_CGROUP_{G,S}ETSOCKOPT cgroup hooks.
> > > > >
> > > > > BPF_CGROUP_SETSOCKOPT get a read-only view of the setsockopt arguments.
> > > > > BPF_CGROUP_GETSOCKOPT can modify the supplied buffer.
> > > > > Both of them reuse existing PTR_TO_PACKET{,_END} infrastructure.
> > > > >
> > > > > The buffer memory is pre-allocated (because I don't think there is
> > > > > a precedent for working with __user memory from bpf). This might be
> > > > > slow to do for each {s,g}etsockopt call, that's why I've added
> > > > > __cgroup_bpf_prog_array_is_empty that exits early if there is nothing
> > > > > attached to a cgroup. Note, however, that there is a race between
> > > > > __cgroup_bpf_prog_array_is_empty and BPF_PROG_RUN_ARRAY where cgroup
> > > > > program layout might have changed; this should not be a problem
> > > > > because in general there is a race between multiple calls to
> > > > > {s,g}etsocktop and user adding/removing bpf progs from a cgroup.
> > > > >
> > > > > The return code of the BPF program is handled as follows:
> > > > > * 0: EPERM
> > > > > * 1: success, execute kernel {s,g}etsockopt path after BPF prog exits
> > > > > * 2: success, do _not_ execute kernel {s,g}etsockopt path after BPF
> > > > > prog exits
> > > > >
> > > > > Note that if 0 or 2 is returned from BPF program, no further BPF program
> > > > > in the cgroup hierarchy is executed. This is in contrast with any existing
> > > > > per-cgroup BPF attach_type.
> > > >
> > > > This is drastically different from all other cgroup-bpf progs.
> > > > I think all programs should be executed regardless of return code.
> > > > It seems to me that 1 vs 2 difference can be expressed via bpf program logic
> > > > instead of return code.
> > > >
> > > > How about we do what all other cgroup-bpf progs do:
> > > > "any no is no. all yes is yes"
> > > > Meaning any ret=0 - EPERM back to user.
> > > > If all are ret=1 - kernel handles get/set.
> > > >
> > > > I think the desire to differentiate 1 vs 2 came from ordering issue
> > > > on getsockopt.
> > > > How about for setsockopt all progs run first and then kernel.
> > > > For getsockopt kernel runs first and then all progs.
> > > > Then progs will have an ability to overwrite anything the kernel returns.
> > > Good idea, makes sense. For getsockopt we'd also need to pass the return
> > > value of the kernel getsockopt to let bpf programs override it, but seems
> > > doable. Let me play with it a bit; I'll send another version if nothing
> > > major comes up.
> > >
> > > Thanks for another round of review!
> > One clarification: we'd still probably need to have 3 return codes for
> > setsockopt:
> > * any 0 - EPERM
> > * all 1 - continue with the kernel path (i.e. apply this sockopt as is)
> > * any 2 - return after all BPF hooks are executed (bypass kernel)
> > (any 0 trumps any 2 -> EPERM)
> >
> > The context is readonly for setsockopt, so it shouldn't be an issue.
> > Let me know if you have better idea how to handle that.
>
> I think we don't really need 2.
> The progs can reduce optlen to zero (or optname to BPF_EMPTY_SOCKOPT)
> and do ret=1.
> Then the kernel can see that nothing to be be done and return 0 to user space.
> Since parent prog in the chain will be able to see that child prog
> set optlen to zero, it will be able to overwrite if necessary.
Ack, optlen=0 sounds good. In that case parent prog can poke into optval
because optval_end still points to the valid end of the data (and, as you
said, can override optlen back if necessary). Thanks!
> getsockopt wil be clean as well.
> all 1s return whatever was produced by progs to user space.
> and progs will be able to see what kernel wanted to return because
> the kernel's getsockopt logic ran first.
> ret=2 doesn't have any meaning for getsockopt, so nice to keep
> setsockopt symmetrical and don't do it there either.
Agreed.
^ permalink raw reply
* Re: [PATCH rdma-next v1 00/12] DEVX asynchronous events
From: Saeed Mahameed @ 2019-06-18 18:51 UTC (permalink / raw)
To: Jason Gunthorpe, leon@kernel.org, dledford@redhat.com
Cc: Yishai Hadas, netdev@vger.kernel.org, Leon Romanovsky,
linux-rdma@vger.kernel.org
In-Reply-To: <20190618171540.11729-1-leon@kernel.org>
On Tue, 2019-06-18 at 20:15 +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Changelog:
> v0 -> v1:
Normally 1st submission is V1 and 2nd is V2.
so this should have been v1->v2.
For mlx5-next patches:
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
> * Fix the unbind / hot unplug flows to work properly.
> * Fix Ref count handling on the eventfd mode in some flow.
> * Rebased to latest rdma-next
>
> Thanks
>
> -------------------------------------------------------------------
> -----------------
> From Yishai:
>
> This series enables RDMA applications that use the DEVX interface to
> subscribe and read device asynchronous events.
>
> The solution is designed to allow extension of events in the future
> without need to perform any changes in the driver code.
>
> To enable that few changes had been done in mlx5_core, it includes:
> * Reading device event capabilities that are user related
> (affiliated and un-affiliated) and set the matching mask upon
> creating the matching EQ.
> * Enable DEVX/mlx5_ib to register for ANY event instead of the
> option to
> get some hard-coded ones.
> * Enable DEVX/mlx5_ib to get the device raw data for CQ completion
> events.
> * Enhance mlx5_core_create/destroy CQ to enable DEVX using them so
> that CQ
> events will be reported as well.
>
> In mlx5_ib layer the below changes were done:
> * A new DEVX API was introduced to allocate an event channel by
> using
> the uverbs FD object type.
> * Implement the FD channel operations to enable read/poo/close over
> it.
> * A new DEVX API was introduced to subscribe for specific events
> over an
> event channel.
> * Manage an internal data structure over XA(s) to
> subscribe/dispatch events
> over the different event channels.
> * Use from DEVX the mlx5_core APIs to create/destroy a CQ to be able
> to
> get its relevant events.
>
> Yishai
>
> Yishai Hadas (12):
> net/mlx5: Fix mlx5_core_destroy_cq() error flow
> net/mlx5: Use event mask based on device capabilities
> net/mlx5: Expose the API to register for ANY event
> net/mlx5: mlx5_core_create_cq() enhancements
> net/mlx5: Report a CQ error event only when a handler was set
> net/mlx5: Report EQE data upon CQ completion
> net/mlx5: Expose device definitions for object events
> IB/mlx5: Introduce MLX5_IB_OBJECT_DEVX_ASYNC_EVENT_FD
> IB/mlx5: Register DEVX with mlx5_core to get async events
> IB/mlx5: Enable subscription for device events over DEVX
> IB/mlx5: Implement DEVX dispatching event
> IB/mlx5: Add DEVX support for CQ events
>
> drivers/infiniband/hw/mlx5/cq.c | 5 +-
> drivers/infiniband/hw/mlx5/devx.c | 1082
> ++++++++++++++++-
> drivers/infiniband/hw/mlx5/main.c | 10 +-
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 12 +
> drivers/infiniband/hw/mlx5/odp.c | 3 +-
> drivers/infiniband/hw/mlx5/qp.c | 2 +-
> drivers/net/ethernet/mellanox/mlx5/core/cq.c | 21 +-
> drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +-
> .../net/ethernet/mellanox/mlx5/core/en_main.c | 3 +-
> .../net/ethernet/mellanox/mlx5/core/en_txrx.c | 2 +-
> drivers/net/ethernet/mellanox/mlx5/core/eq.c | 68 +-
> .../ethernet/mellanox/mlx5/core/fpga/conn.c | 6 +-
> drivers/net/ethernet/mellanox/mlx5/core/fw.c | 6 +
> .../net/ethernet/mellanox/mlx5/core/lib/eq.h | 5 +-
> include/linux/mlx5/cq.h | 6 +-
> include/linux/mlx5/device.h | 6 +-
> include/linux/mlx5/driver.h | 2 +
> include/linux/mlx5/eq.h | 4 +-
> include/linux/mlx5/mlx5_ifc.h | 34 +-
> include/uapi/rdma/mlx5_user_ioctl_cmds.h | 19 +
> include/uapi/rdma/mlx5_user_ioctl_verbs.h | 9 +
> 21 files changed, 1237 insertions(+), 70 deletions(-)
>
> --
> 2.20.1
>
^ 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