* [PATCH 1/2] dt-binding: mediatek: Add binding document for MediaTek GMAC
From: Biao Huang @ 2018-09-17 6:29 UTC (permalink / raw)
To: davem, robh+dt
Cc: honghui.zhang, yt.shen, liguo.zhang, mark.rutland, sean.wang,
nelson.chang, matthias.bgg, biao.huang, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <1537165763-13112-1-git-send-email-biao.huang@mediatek.com>
The commit adds the device tree binding documentation for the MediaTek
GMAC found on Mediatek MT2712.
Signed-off-by: Biao Huang <biao.huang@mediatek.com>
---
.../devicetree/bindings/net/mediatek-gmac.txt | 45 ++++++++++++++++++++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mediatek-gmac.txt
diff --git a/Documentation/devicetree/bindings/net/mediatek-gmac.txt b/Documentation/devicetree/bindings/net/mediatek-gmac.txt
new file mode 100644
index 0000000..14876ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mediatek-gmac.txt
@@ -0,0 +1,45 @@
+MediaTek Gigabit Ethernet controller
+=========================================
+
+The gigabit ethernet controller can be found on MediaTek SoCs.
+
+* Ethernet controller node
+
+Required properties:
+- compatible: Should be
+ "mediatek,mt2712-eth": for MT2712 SoC
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the MAC interrupts
+- interrupt-names: the name of interrupt in the interrupts property. These are
+ "macirq": For MT2712 SoC
+- clocks: the clock used by the controller
+- clock-names: the names of the clock listed in the clocks property. These are
+ "axi", "apb", "mac_ext", "ptp", "ptp_parent", "ptp_top": For MT2712 SoC
+- mac-address: See ethernet.txt in the same directory
+- power-domains: phandle to the power domain that the ethernet is part of
+- phy-mode: See ethernet.txt file in the same directory.
+- reset-gpio: gpio number for phy reset.
+
+Example:
+
+eth: eth@1101c000 {
+ compatible = "mediatek,mt2712-eth";
+ reg = <0 0x1101c000 0 0x1200>;
+ interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "macirq";
+ phy-mode ="rgmii";
+ mac-address = [00 55 7b b5 7d f7];
+ clock-names = "axi",
+ "apb",
+ "mac_ext",
+ "ptp",
+ "ptp_parent",
+ "ptp_top";
+ clocks = <&pericfg CLK_PERI_GMAC>,
+ <&pericfg CLK_PERI_GMAC_PCLK>,
+ <&topckgen CLK_TOP_ETHER_125M_SEL>,
+ <&topckgen CLK_TOP_ETHER_50M_SEL>,
+ <&topckgen CLK_TOP_APLL1_D3>,
+ <&topckgen CLK_TOP_APLL1>;
+ reset-gpio = <&pio 87 GPIO_ACTIVE_HIGH>;
+ };
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] add Ethernet driver support for mt2712
From: Biao Huang @ 2018-09-17 6:29 UTC (permalink / raw)
To: davem, robh+dt
Cc: honghui.zhang, yt.shen, liguo.zhang, mark.rutland, sean.wang,
nelson.chang, matthias.bgg, biao.huang, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
Ethernet in mt2712 is totally different from that in
drivers/net/ethernet/mediatek/*, so we add new folder for mt2712 SoC.
The mt2712 Ethernet IP is from Synopsys, and we notice that there is a
reference driver in drivers/net/ethernet/synopsys/*. But
1. our version is only for 10/100/1000Mbps, not for 2.5/4/5Gbps.
mt2712 Ethernet design is differnet from that in synopsys folder in many
aspects, and some key features are not included in mt2712, such as rss
and split header. At the same time, some features we need have not been
implenmented in synopsys folder.
2. MediaTek will lauch new products base on this version continously, and
there will be modifications between these products.
so, we'd better maintain MediaTek's Ethernet driver to support synopsys-ip
based products. And we adopt the frameworks in synopsys/* to develop
Ethernet driver in mt2712.
^ permalink raw reply
* Re: [PATCH 1/1] net: rds: use memset to optimize the recv
From: zhuyj @ 2018-09-17 0:54 UTC (permalink / raw)
To: David S. Miller
Cc: yanjun.zhu, santosh.shilimkar, netdev, linux-rdma, rds-devel
In-Reply-To: <20180916.153637.2289306962750648161.davem@davemloft.net>
OK. I will send V2 for net-next very soon.
Zhu Yanjun
On Mon, Sep 17, 2018 at 6:38 AM David Miller <davem@davemloft.net> wrote:
>
> From: Zhu Yanjun <yanjun.zhu@oracle.com>
> Date: Fri, 14 Sep 2018 04:45:38 -0400
>
> > The function rds_inc_init is in recv process. To use memset can optimize
> > the function rds_inc_init.
> > The test result:
> >
> > Before:
> > 1) + 24.950 us | rds_inc_init [rds]();
> > After:
> > 1) + 10.990 us | rds_inc_init [rds]();
> >
> > Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
>
> This doesn't apply cleanly to net-next, please respin.
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: marvell, prestera: Add common compatible string
From: Rob Herring @ 2018-09-17 5:45 UTC (permalink / raw)
To: Chris Packham
Cc: Mark Rutland, andrew, jason, devicetree, netdev, gregory.clement,
linux-kernel, robh+dt, Chris Packham, davem, linux-arm-kernel,
sebastian.hesselbarth
In-Reply-To: <20180907005926.27134-2-chris.packham@alliedtelesis.co.nz>
On Fri, 7 Sep 2018 12:59:25 +1200, Chris Packham wrote:
> Add "marvell,prestera" as a compatible string so that drivers can be
> written to account for any prestera variant without needing to
> specialise to the more specific values.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> Documentation/devicetree/bindings/net/marvell,prestera.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Ard Biesheuvel @ 2018-09-17 5:26 UTC (permalink / raw)
To: Andy Lutomirski
Cc: David S. Miller, Andrew Lunn, Jason A. Donenfeld, Eric Biggers,
Greg KH, LKML, Network Development, Samuel Neves,
Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <CALCETrXrJPcs3h9CtF50N4k2AGx3qzspJd_UW3t+KGYOj7+p=Q@mail.gmail.com>
On 17 September 2018 at 06:09, Andy Lutomirski <luto@kernel.org> wrote:
> On Tue, Sep 11, 2018 at 4:57 PM David Miller <davem@davemloft.net> wrote:
>>
>> From: Andrew Lunn <andrew@lunn.ch>
>> Date: Wed, 12 Sep 2018 01:30:15 +0200
>>
>> > Just as an FYI:
>> >
>> > 1) I don't think anybody in netdev has taken a serious look at the
>> > network code yet. There is little point until the controversial part
>> > of the code, Zinc, has been sorted out.
>> >
>> > 2) I personally would be surprised if DaveM took this code without
>> > having an Acked-by from the crypto subsystem people. In the same way,
>> > i doubt the crypto people would take an Ethernet driver without having
>> > DaveM's Acked-by.
>>
>> Both of Andrew's statements are completely true.
>>
>> I'm not looking at any of the networking bits until the crypto stuff
>> is fully sorted and fully supported and Ack'd by crypto folks.
>
> So, as a process question, whom exactly are we waiting for:
>
> CRYPTO API
> M: Herbert Xu <herbert@gondor.apana.org.au>
> M: "David S. Miller" <davem@davemloft.net>
> L: linux-crypto@vger.kernel.org
>
> Herbert hasn't replied to any of these submissions. You're the other
> maintainer :)
>
> To the extent that you (DaveM) want my ack, here's what I think of the
> series so far:
>
> The new APIs to the crypto primitives are good. For code that wants
> to do a specific known crypto operation, they are much, much more
> pleasant to use than the existing crypto API. The code cleanups in
> the big keys patch speak for themselves IMO. I have no problem with
> the addition of a brand-new API to the kernel, especially when it's a
> nice one like Zinc's, even if that API starts out with only a couple
> of users.
>
> Zinc's arrangement of arch code is just fine. Sure, there are
> arguments that putting arch-specific code in arch/ is better, but this
> is mostly bikeshedding IMO.
>
> There has been some discussion of the exact best way to handle
> simd_relax() and some other minor nitpicks of API details. This kind
> of stuff doesn't need to block the series -- it can always be reworked
> down the road if needed.
>
> There are two things I don't like right now, though:
>
> 1. Zinc conflates the addition of a new API with the replacement of
> some algorithm implementations. This is problematic. Look at the
> recent benchmarks of ipsec before and after this series. Apparently
> big packets get faster and small packets get slower. It would be
> really nice to bisect the series to narrow down *where* the regression
> came from, but, as currently structured, you can't.
>
> The right way to do this is to rearrange the series. First, the new
> Zinc APIs should be added, and they should be backed with the
> *existing* crypto code. (If the code needs to be moved or copied to a
> new location, so be it. The patch will be messy because somehow the
> Zinc API is going to have to dispatch to the arch-specific code, and
> the way that the crypto API handles it is not exactly friendly to this
> type of use. So be it.) Then another patch should switch the crypto
> API to use the Zinc interface. That patch, *by itself*, can be
> benchmarked. If it causes a regression for small ipsec packets, then
> it can be tracked down relatively easily. Once this is all done, the
> actual crypto implementation can be changed, and that changed can be
> reviewed on its own merits.
>
> As a simplistic example, I wrote this code a while back:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=crypto/sha256_bpf&id=e9e12f056f2abed50a30b762db9185799f5864e6
>
> and its two parents. This series added a more Zinc-like API to
> SHA256. And it did it without replacing the SHA256 implementation.
> Doing this for Zinc would be a bit more complication, since the arch
> code would need to be invoked too, but it should be doable.
>
> FWIW, Wireguard should not actually depend on the replacement of the
> crypto implementation.
>
> 2. The new Zinc crypto implementations look like they're brand new. I
> realize that they have some history, some of them are derived from
> OpenSSL, etc, but none of this is really apparent in the patches
> themselves. It would be great if the kernel could literally share the
> same code as something like OpenSSL, since OpenSSL gets much more
> attention than the kernel's crypto. Failing that, it would be nice if
> the patches made it more clear how the code differs from its origin.
> At the very least, though, if the replacement of the crypto code were,
> as above, a patch that just replaced the crypto code, it would be much
> easier to review and benchmark intelligently.
>
OK, so let me summarize my remaining concerns as well. I may be a bit
more finicky than Andy, though.
First of all, the rate at which new revisions of this series are
appearing increases the review effort unnecessarily, especially given
that the latest version seemed to have some issues that would have
been spotted by a simple build test. I would like to urge Jason to
bear with us and bring this discussion to a close before resubmitting.
As far as I can tell (i.e., as a user not a network dev), WireGuard is
an excellent piece of code, and I would like to see it merged. I also
think there is little disagreement about the quality of the proposed
algorithm implementations and the usefulness of having a set of easy
to use solid crypto primitives in addition to or complementing the
current crypto API.
I do have some concerns over how the code is organized though:
* simd_relax() is currently not called by the crypto routines
themselves. This means that the worst case scheduling latency is
unbounded, which is unacceptable for the -rt kernel. The worst case
scheduling latency should never be proportional to the input size.
(Apologies for not spotting that earlier)
* Using a cute name for the crypto library [that will end up being the
preferred choice for casual use only] may confuse people, given that
we have lots of code in crypto/ already. I'd much prefer using, e.g.,
crypto/lib and crypto/api (regardless of where the arch specific
pieces live)
* I'd prefer the arch specific pieces to live under arch, but I can
live with keeping them in a single place, as long as the arch
maintainers have some kind of jurisdiction over them. I also think
there should be some overlap between the maintainership
responsibilities of the two generic pieces (api and lib).
* (Nit) The GCC command line -include'd .h files contain variable and
function definitions so they are actually .c files.
* (Nit) Referencing CONFIG_xxx macros from -include'd files adds the
implicit assumption that the -include appears after the -include of
kconfig.h.
* Adding /conditional/ -include's (or #include's) increases the size
of the validation space, which is why we generally prefer
unconditional includes (and static inline stubs), and 'if
(IS_ENABLED(CONFIG_xxx))' over #ifdef CONFIG_xxx
* The current organization of the code puts all available (for the
arch) versions of all routines into a single module, which can only be
built in once we update random.c to use Zinc's chacha20 routines. This
bloats the core kernel (which is a huge deal for embedded systems that
have very strict boot requirements). It also makes it impossible to
simply blacklist a module if you, for instance, prefer to use the
[potentially more power efficient] scalar code over the SIMD code when
using a distro kernel.
[To summarize the 4 points above, I'd much rather see a more
conventional organization where different parts are provided by
different modules. I don't think the argument that inlining is needed
for performance is actually valid, given that we have branch
predictors and static keys, and the arch SIMD code is built as
separate object files anyway]
* If we reuse source files from OpenSSL, we should use that actual
source which is the perlasm not the emitted assembler. Also, we should
work with Andy Polyakov (as I have done several times over the past 5+
years) to upstream the changes we apply to the kernel version of the
code. The same applies to code from other sources, btw, but I am not
personally familiar with them.
* If upstreaming the changes is not an option, they should be applied
as a separate patch and not hidden in a 5000 line patch without any
justification or documentation (but Jason is already working on that)
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Jason A. Donenfeld @ 2018-09-17 5:07 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: David Miller, Andrew Lunn, Eric Biggers, Greg Kroah-Hartman,
Ard Biesheuvel, LKML, Netdev, Samuel Neves,
Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <CALCETrXrJPcs3h9CtF50N4k2AGx3qzspJd_UW3t+KGYOj7+p=Q@mail.gmail.com>
Hey Andy,
Thanks a lot for your feedback.
On Mon, Sep 17, 2018 at 6:09 AM Andy Lutomirski <luto@kernel.org> wrote:
> 1. Zinc conflates the addition of a new API with the replacement of
> some algorithm implementations. This is problematic. Look at the
> recent benchmarks of ipsec before and after this series. Apparently
> big packets get faster and small packets get slower. It would be
> really nice to bisect the series to narrow down *where* the regression
> came from, but, as currently structured, you can't.
>
> The right way to do this is to rearrange the series. First, the new
> Zinc APIs should be added, and they should be backed with the
> *existing* crypto code. (If the code needs to be moved or copied to a
> new location, so be it. The patch will be messy because somehow the
> Zinc API is going to have to dispatch to the arch-specific code, and
> the way that the crypto API handles it is not exactly friendly to this
> type of use. So be it.) Then another patch should switch the crypto
> API to use the Zinc interface. That patch, *by itself*, can be
> benchmarked. If it causes a regression for small ipsec packets, then
> it can be tracked down relatively easily. Once this is all done, the
> actual crypto implementation can be changed, and that changed can be
> reviewed on its own merits.
That ipsec regression was less related to the implementation and more
related to calling kernel_fpu_begin() unnecessarily, something I've
now fixed. So I'm not sure that's such a good example. However, I can
try to implement Zinc over the existing assembly (Martin's and Ard's),
first, as you've described. This will be a pretty large amount of
work, but if you think it's worth it for the commit history, then I'll
do it.
> 2. The new Zinc crypto implementations look like they're brand new. I
> realize that they have some history, some of them are derived from
> OpenSSL, etc, but none of this is really apparent in the patches
> themselves.
The whole point of going with these is that they _aren't_ brand new,
yet they are very fast. Eyeballs and fuzzer hours are important, and
AndyP's seems to get the most eyeballs and fuzzer hours, generally.
> it would be nice if
> the patches made it more clear how the code differs from its origin.
> At the very least, though, if the replacement of the crypto code were,
> as above, a patch that just replaced the crypto code, it would be much
> easier to review and benchmark intelligently.
You seem to have replied to the v3 thread, not the v4 thread. I've
already started to include lots of detail about the origins of the
code and [any] important differences in v4, and I'll continue to add
more detail for v5.
On <https://git.zx2c4.com/linux-dev/log/>, have a look at AndyP's x86_64 ones:
- zinc: ChaCha20 x86_64 implementation
- zinc: Poly1305 x86_64 implementation
For the arm/arm64 ones, the changes were even more trivial, so much so
that at Ard's urging, I included a cleaned-up diff inside the commit
message:
- zinc: ChaCha20 ARM and ARM64 implementations
- zinc: Poly1305 ARM and ARM64 implementations
How's that level of detail looking to you?
Thanks again for the review.
Regards,
Jason
^ permalink raw reply
* Re: [PATCH net-next v4 18/20] crypto: port ChaCha20 to Zinc
From: Jason A. Donenfeld @ 2018-09-17 4:54 UTC (permalink / raw)
To: Martin Willi
Cc: LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson, Eric Biggers
In-Reply-To: <72e893e7efbef428d4fd23b7332d9e829acd5e7d.camel@strongswan.org>
Hey Martin,
Thanks for running these and pointing this out. I've replicated the
results with tcrypt and fixed some issues, and the next patch series
should be a lot closer to what you'd expect, instead of the regression
you noticed. Most of the slowdown happened as a result of over-eager
XSAVEs, which I've now rectified. I'm still working on a few other
facets of it, but I believe v5 will be more satisfactory when posted.
Regards,
Jason
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: David Miller @ 2018-09-17 4:45 UTC (permalink / raw)
To: luto
Cc: andrew, Jason, ebiggers, gregkh, ard.biesheuvel, linux-kernel,
netdev, sneves, jeanphilippe.aumasson, linux-crypto
In-Reply-To: <CALCETrXrJPcs3h9CtF50N4k2AGx3qzspJd_UW3t+KGYOj7+p=Q@mail.gmail.com>
From: Andy Lutomirski <luto@kernel.org>
Date: Sun, 16 Sep 2018 21:09:11 -0700
> CRYPTO API
> M: Herbert Xu <herbert@gondor.apana.org.au>
> M: "David S. Miller" <davem@davemloft.net>
> L: linux-crypto@vger.kernel.org
>
> Herbert hasn't replied to any of these submissions. You're the other
> maintainer :)
Herbert is the primary crypto maintainer, I haven't done a serious
review of crypto code in ages.
So yes, Herbert review is what is important here.
^ permalink raw reply
* Re: kernel 4.18.5 Realtek 8111G network adapter stops responding under high system load
From: Maciej S. Szmigiero @ 2018-09-16 23:11 UTC (permalink / raw)
To: David Arendt; +Cc: linux-kernel, nic_swsd, netdev, Heiner Kallweit
In-Reply-To: <236d01e8-865a-e5e8-7537-197657afb34b@prnet.org>
On 16.09.2018 14:38, David Arendt wrote:
> Hi,
>
(..)
>
> For information here the differences from ethtool between the working
> driver from 4.17.14 and the patched one fom 4.18.8:
>
> --- working.txt 2018-09-16 14:14:00.544376935 +0200
> +++ patched.txt 2018-09-16 14:20:09.445660915 +0200
> @@ -17 +17 @@
> -0x40: Tx Configuration 0x4f000f80
> +0x40: Tx Configuration 0x4f000f00
TXCFG_AUTO_FIFO was set by the working driver in TxConfig but the current
driver version seems unable to do it.
Looking at your NIC model config code (guess it is XID 4c000800 or
RTL_GIGA_MAC_VER_40) that bit should be set by rtl_hw_start_8168g(),
that is called from rtl_hw_start_8168g_1(), that in turn is called
from rtl_hw_start_8168().
However, after rtl_hw_start_8168() is called from rtl_hw_start()
(as tp->hw_start(tp)) a call to rtl_set_tx_config_registers() is made
which overwrites TxConfig completely, zeroing the aforementioned bit.
It looks like this was first introduced by commit
4fd48c4ac0a0 ("r8169: move common initializations to tp->hw_start").
I have added its author (Heiner Kallweit) to CC.
@Heiner: could you have a look at this?
Maciej
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Andy Lutomirski @ 2018-09-17 4:09 UTC (permalink / raw)
To: David S. Miller
Cc: andrew, Jason A. Donenfeld, Eric Biggers, Greg KH, Ard Biesheuvel,
LKML, Network Development, Andrew Lutomirski, Samuel Neves,
Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <20180911.165739.2032677219588723041.davem@davemloft.net>
On Tue, Sep 11, 2018 at 4:57 PM David Miller <davem@davemloft.net> wrote:
>
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Wed, 12 Sep 2018 01:30:15 +0200
>
> > Just as an FYI:
> >
> > 1) I don't think anybody in netdev has taken a serious look at the
> > network code yet. There is little point until the controversial part
> > of the code, Zinc, has been sorted out.
> >
> > 2) I personally would be surprised if DaveM took this code without
> > having an Acked-by from the crypto subsystem people. In the same way,
> > i doubt the crypto people would take an Ethernet driver without having
> > DaveM's Acked-by.
>
> Both of Andrew's statements are completely true.
>
> I'm not looking at any of the networking bits until the crypto stuff
> is fully sorted and fully supported and Ack'd by crypto folks.
So, as a process question, whom exactly are we waiting for:
CRYPTO API
M: Herbert Xu <herbert@gondor.apana.org.au>
M: "David S. Miller" <davem@davemloft.net>
L: linux-crypto@vger.kernel.org
Herbert hasn't replied to any of these submissions. You're the other
maintainer :)
To the extent that you (DaveM) want my ack, here's what I think of the
series so far:
The new APIs to the crypto primitives are good. For code that wants
to do a specific known crypto operation, they are much, much more
pleasant to use than the existing crypto API. The code cleanups in
the big keys patch speak for themselves IMO. I have no problem with
the addition of a brand-new API to the kernel, especially when it's a
nice one like Zinc's, even if that API starts out with only a couple
of users.
Zinc's arrangement of arch code is just fine. Sure, there are
arguments that putting arch-specific code in arch/ is better, but this
is mostly bikeshedding IMO.
There has been some discussion of the exact best way to handle
simd_relax() and some other minor nitpicks of API details. This kind
of stuff doesn't need to block the series -- it can always be reworked
down the road if needed.
There are two things I don't like right now, though:
1. Zinc conflates the addition of a new API with the replacement of
some algorithm implementations. This is problematic. Look at the
recent benchmarks of ipsec before and after this series. Apparently
big packets get faster and small packets get slower. It would be
really nice to bisect the series to narrow down *where* the regression
came from, but, as currently structured, you can't.
The right way to do this is to rearrange the series. First, the new
Zinc APIs should be added, and they should be backed with the
*existing* crypto code. (If the code needs to be moved or copied to a
new location, so be it. The patch will be messy because somehow the
Zinc API is going to have to dispatch to the arch-specific code, and
the way that the crypto API handles it is not exactly friendly to this
type of use. So be it.) Then another patch should switch the crypto
API to use the Zinc interface. That patch, *by itself*, can be
benchmarked. If it causes a regression for small ipsec packets, then
it can be tracked down relatively easily. Once this is all done, the
actual crypto implementation can be changed, and that changed can be
reviewed on its own merits.
As a simplistic example, I wrote this code a while back:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=crypto/sha256_bpf&id=e9e12f056f2abed50a30b762db9185799f5864e6
and its two parents. This series added a more Zinc-like API to
SHA256. And it did it without replacing the SHA256 implementation.
Doing this for Zinc would be a bit more complication, since the arch
code would need to be invoked too, but it should be doable.
FWIW, Wireguard should not actually depend on the replacement of the
crypto implementation.
2. The new Zinc crypto implementations look like they're brand new. I
realize that they have some history, some of them are derived from
OpenSSL, etc, but none of this is really apparent in the patches
themselves. It would be great if the kernel could literally share the
same code as something like OpenSSL, since OpenSSL gets much more
attention than the kernel's crypto. Failing that, it would be nice if
the patches made it more clear how the code differs from its origin.
At the very least, though, if the replacement of the crypto code were,
as above, a patch that just replaced the crypto code, it would be much
easier to review and benchmark intelligently.
--Andy
^ permalink raw reply
* Re: [PATCH 1/1] net: rds: use memset to optimize the recv
From: David Miller @ 2018-09-16 22:36 UTC (permalink / raw)
To: yanjun.zhu; +Cc: santosh.shilimkar, netdev, linux-rdma, rds-devel
In-Reply-To: <20180914084538.11666-1-yanjun.zhu@oracle.com>
From: Zhu Yanjun <yanjun.zhu@oracle.com>
Date: Fri, 14 Sep 2018 04:45:38 -0400
> The function rds_inc_init is in recv process. To use memset can optimize
> the function rds_inc_init.
> The test result:
>
> Before:
> 1) + 24.950 us | rds_inc_init [rds]();
> After:
> 1) + 10.990 us | rds_inc_init [rds]();
>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
This doesn't apply cleanly to net-next, please respin.
^ permalink raw reply
* Re: [PATCH net] veth: Orphan skb before GRO
From: David Miller @ 2018-09-16 22:34 UTC (permalink / raw)
To: makita.toshiaki; +Cc: netdev, pabeni, eric.dumazet
In-Reply-To: <1536899624-2438-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date: Fri, 14 Sep 2018 13:33:44 +0900
> GRO expects skbs not to be owned by sockets, but when XDP is enabled veth
> passed skbs owned by sockets. It caused corrupted sk_wmem_alloc.
>
> Paolo Abeni reported the following splat:
...
> In order to avoid this, orphan the skb before entering GRO.
>
> Fixes: 948d4f214fde ("veth: Add driver XDP")
> Reported-by: Paolo Abeni <pabeni@redhat.com>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3,net-next 2/2] ip6_gre: simplify gre header parsing in ip6gre_err
From: David Miller @ 2018-09-16 22:34 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, jbenc, netdev, linux-kernel
In-Reply-To: <1536899208-2958-2-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Fri, 14 Sep 2018 12:26:48 +0800
> Same as ip_gre, use gre_parse_header to parse gre header in gre error
> handler code.
>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net/smc: cast sizeof to int for comparison
From: YueHaibing @ 2018-09-17 3:57 UTC (permalink / raw)
To: Andreas Schwab; +Cc: davem, ubraun, linux-kernel, netdev, linux-s390
In-Reply-To: <87zhwj6liz.fsf@igel.home>
On 2018/9/15 19:35, Andreas Schwab wrote:
> On Sep 15 2018, YueHaibing <yuehaibing@huawei.com> wrote:
>
>> Comparing an int to a size, which is unsigned, causes the int to become
>> unsigned, giving the wrong result. kernel_sendmsg can return a negative
>> error code.
>>
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>> ---
>> net/smc/smc_clc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/smc/smc_clc.c b/net/smc/smc_clc.c
>> index 83aba9a..fd0f5ce 100644
>> --- a/net/smc/smc_clc.c
>> +++ b/net/smc/smc_clc.c
>> @@ -446,7 +446,7 @@ int smc_clc_send_proposal(struct smc_sock *smc, int smc_type,
>> vec[i++].iov_len = sizeof(trl);
>> /* due to the few bytes needed for clc-handshake this cannot block */
>> len = kernel_sendmsg(smc->clcsock, &msg, vec, i, plen);
>> - if (len < sizeof(pclc)) {
>> + if (len < (int)sizeof(pclc)) {
>> if (len >= 0) {
>> reason_code = -ENETUNREACH;
>> smc->sk.sk_err = -reason_code;
>
> It would perhaps be better to handle len < 0 first.
That need refactor the err hangding, is worth doing it?
>
> Andreas.
>
^ permalink raw reply
* Re: [PATCH net-next 0/2] net/sched: act_police: lockless data path
From: David Miller @ 2018-09-16 22:32 UTC (permalink / raw)
To: dcaratti; +Cc: jhs, xiyou.wangcong, jiri, netdev
In-Reply-To: <cover.1536852493.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Thu, 13 Sep 2018 19:29:11 +0200
> the data path of 'police' action can be faster if we avoid using spinlocks:
> - patch 1 converts act_police to use per-cpu counters
> - patch 2 lets act_police use RCU to access its configuration data.
>
> test procedure (using pktgen from https://github.com/netoptimizer):
> # ip link add name eth1 type dummy
> # ip link set dev eth1 up
> # tc qdisc add dev eth1 clsact
> # tc filter add dev eth1 egress matchall action police \
> > rate 2gbit burst 100k conform-exceed pass/pass index 100
> # for c in 1 2 4; do
> > ./pktgen_bench_xmit_mode_queue_xmit.sh -v -s 64 -t $c -n 5000000 -i eth1
> > done
>
> test results (avg. pps/thread):
>
> $c | before patch | after patch | improvement
> ----+--------------+--------------+-------------
> 1 | 3518448 | 3591240 | irrelevant
> 2 | 3070065 | 3383393 | 10%
> 4 | 1540969 | 3238385 | 110%
Series applied.
^ permalink raw reply
* Re: [PATCH net 0/2] udp: add missing check on edumx rx path
From: David Miller @ 2018-09-16 22:28 UTC (permalink / raw)
To: pabeni; +Cc: netdev, tom
In-Reply-To: <cover.1536848512.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Thu, 13 Sep 2018 16:27:19 +0200
> The early demux RX path for the UDP protocol is currently missing
> some checks. Both ipv4 and ipv6 implementations lack checksum conversion
> and the ipv6 implementation additionally lack the zero checksum
> validation.
>
> The first patch takes care of UDPv4 and the second one of UDPv6
Series applied and queued up for -stable.
^ permalink raw reply
* Oddities with connmark
From: Алексей Болдырев @ 2018-09-16 21:16 UTC (permalink / raw)
To: netdev
Actually, there is a suricata with the following rules:
#pass tls any any -> any any (pcre: "/play.google.com/i"; tls_sni;nfq_set_mark:0x8/0xffffffff; sid:2466;)
#pass tls any any -> any any (pcre: "/google.com/i"; tls_sni;nfq_set_mark:0x8/0xffffffff; sid:2465;)
#pass tls any any -> any any (pcre: "/gstatic.com/i"; tls_sni;nfq_set_mark:0x8/0xffffffff; sid:2467;)
#pass tls any any -> any any (pcre: "/googleservice.com/i"; tls_sni;nfq_set_mark:0x8/0xffffffff; sid:2467;)
pass tls any any -> any any (pcre: "/youtube.com/s"; tls_sni;nfq_set_mark:0x2/0xffffffff; sid:2455;)
pass tls any any -> any any (pcre: "/googlevideo.com/s"; tls_sni;nfq_set_mark:0x2/0xffffffff; sid:2456;)
pass http any any <> any any (content: "tactical-market.ru"; http_header;nfq_set_mark:0x4/0xffffffff; sid:2457;)
pass http any any <> any any (content: "voent.org"; http_header;nfq_set_mark:0x4/0xffffffff; sid:2458;)
pass http any any <> any any (content: "h-mag.ru"; http_header;nfq_set_mark:0x4/0xffffffff; sid:2459;)
pass tls any any <> any any (content: "voent.org";tls_sni;nfq_set_mark:0x4/0xffffffff; sid:2460;)
pass tls any any <> any any (content: "h-mag.ru";tls_sni;nfq_set_mark:0x4/0xffffffff; sid:2461;)
rejectboth tcp any any <> any any (content: "GET http://";content: "Host: "; sid:2462;)
pass http any any <> any any (content: "302";http_stat_code;content: "ivrn.net";http_header;nfq_set_mark:0x64/0xffffffff; sid:2463;)
pass ssh any any <> any any (nfq_set_mark:0x6/0xffffffff; sid:2464;)
#reject tls any any <> any any (content:"www.youtube.com"; tls_sni;nfq_set_mark:0x2/0xffffffff; sid:2456;)
#ytimg.com
iptables:
Chain PREROUTING (policy ACCEPT 228K packets, 138M bytes)
pkts bytes target prot opt in out source destination
11 3630 RETURN all -- * * 0.0.0.0 255.255.255.255
127K 121M RETURN all -- eth1 * 0.0.0.0/0 0.0.0.0/0
187 11489 RETURN all -- ppp0 * 0.0.0.0/0 0.0.0.0/0
10365 2323K RETURN all -- vpns0.10 * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 rpfilter invert LOG flags 0 level 4 prefix "IP SPOOFING: "
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 rpfilter invert
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 -m ipv4options --flags 7
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 -m ipv4options --flags 3
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 -m ipv4options --flags 9
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 match-set dpi_detect dst MARK xset 0x40/0xfe
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 match-set dpi_detect src MARK xset 0x40/0xfe
Chain INPUT (policy ACCEPT 107K packets, 45M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 120K packets, 93M bytes)
pkts bytes target prot opt in out source destination
241K 185M DPI all -- * * 0.0.0.0/0 0.0.0.0/0
120K 93M DPI_SH all -- * * 0.0.0.0/0 0.0.0.0/0
2063 123K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT 109K packets, 24M bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 229K packets, 116M bytes)
pkts bytes target prot opt in out source destination
Chain DPI (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 198.18.0.0/15 192.168.0.0/15
0 0 RETURN all -- * * 192.168.0.0/16 198.18.0.0/15
0 0 RETURN all -- * * 192.168.0.0/16 192.168.0.0/16
121K 93M NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 mark match ! 0x1/0x1 NFQUEUE num 0
Chain DPI_SH (1 references)
pkts bytes target prot opt in out source destination
3542 2688K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 connmark match 0x8/0xfe
53 45450 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x8/0xfe CONNMARK xset 0x8/0xfe
0 0 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x4/0xfe CONNMARK xset 0x4/0xfe
8 9366 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x2/0xfe CONNMARK xset 0x2/0xfe
24094 27M CLASSIFY all -- * * 0.0.0.0/0 0.0.0.0/0 connmark match 0x2/0xfe CLASSIFY set 1:11
0 0 CLASSIFY all -- * * 0.0.0.0/0 0.0.0.0/0 connmark match 0x4/0xfe CLASSIFY set 1:12
0 0 SET all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x64/0xfe add-set dpi_detect src
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x64/0xfe LOG flags 0 level 4 prefix "INFOROOM DPI: "
ip6tables:
Chain PREROUTING (policy ACCEPT 314 packets, 60079 bytes)
pkts bytes target prot opt in out source destination
0 0 RETURN all eth1 * ::/0 ::/0
6722 5704K RETURN all ppp0 * ::/0 ::/0
2 112 RETURN all vpns0.10 * ::/0 ::/0
0 0 LOG all * * ::/0 ::/0 rpfilter invert LOG flags 0 level 4 prefix "IP6 SPOOFING: "
0 0 DROP all * * ::/0 ::/0 rpfilter invert
Chain INPUT (policy ACCEPT 15 packets, 984 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 299 packets, 59095 bytes)
pkts bytes target prot opt in out source destination
23065 13M DPI all * * ::/0 ::/0
11539 6450K DPI_SH all * * ::/0 ::/0
172 13760 TCPMSS tcp * * ::/0 ::/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT 13 packets, 896 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 312 packets, 59991 bytes)
pkts bytes target prot opt in out source destination
Chain DPI (1 references)
pkts bytes target prot opt in out source destination
1 1280 RETURN all * * 2a01:d0:c353::/48 2a01:d0:c353::/48
0 0 RETURN all * * 2a01:d0:c353::/48 2a01:d0:c353::/48
11526 6448K NFQUEUE all * * ::/0 ::/0 mark match ! 0x1/0x1 NFQUEUE num 0
Chain DPI_SH (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all * * ::/0 ::/0 connmark match 0x8/0xfe
0 0 CONNMARK all * * ::/0 ::/0 mark match 0x8/0xfe CONNMARK xset 0x8/0xfe
0 0 CONNMARK all * * ::/0 ::/0 mark match 0x4/0xfe CONNMARK xset 0x4/0xfe
31 36225 CONNMARK all * * ::/0 ::/0 mark match 0x2/0xfe CONNMARK xset 0x2/0xfe
215 86776 CLASSIFY all * * ::/0 ::/0 connmark match 0x2/0xfe CLASSIFY set 1:11
0 0 CLASSIFY all * * ::/0 ::/0 connmark match 0x4/0xfe CLASSIFY set 1:12
0 0 LOG all * * ::/0 ::/0 mark match 0x64/0xfe LOG flags 0 level 4 prefix "INFOROOM DPI: "
Now the question: why when going on google.com, the rule
314 115K CLASSIFY all * * ::/0 ::/0 connmark match 0x2/0xfe CLASSIFY set 1:11
starts to work? In theory, it should work if you go to youtube.com.
^ permalink raw reply
* Re: [PATCH] net: ethernet: remove redundant null pointer check before of_node_put
From: Vladimir Zapolskiy @ 2018-09-16 21:11 UTC (permalink / raw)
To: zhong jiang, davem; +Cc: fugang.duan, netdev, linux-kernel
In-Reply-To: <1537103622-63482-1-git-send-email-zhongjiang@huawei.com>
On 09/16/2018 04:13 PM, zhong jiang wrote:
> of_node_put has taken the null pinter check into account. So it is
> safe to remove the duplicated check before of_node_put.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
typo in the commit message, s/pinter/pointer/
Other than that please feel free to add my
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
^ permalink raw reply
* Re: [PATCH RFC net-next] Amiga PCMCIA 100 MBit card support
From: Michael Schmitz @ 2018-09-16 21:09 UTC (permalink / raw)
To: ALeX Kazik, netdev; +Cc: Linux/m68k, Rolf Anders
In-Reply-To: <20180915203338.GA39871@MacBook.local>
Thanks for your patch!
On 16/09/18 08:40, ALeX Kazik wrote:
> This adds an option to change the (10 MBit only) "apne" driver to support
> the 10/100 Mbit cards (e.g. Netgear FA411, CNet Singlepoint) instead.
>
> A new configure option is added as a bool to the apne driver to change the
> behaviour to support some new cards instead.
> The option can be only enabled if no other 8390 driver is active because the
> 8390 library is modified when activated.
>
> The patch is initially from http://www.g-mb.de/pcmcia_e.html and adapted by
> me from the 2.6 version.
>
> The contained reset fix is required to use a pcmcia card after a reset/reboot,
> and is also only activated with new option. (Background, as far as I
> understood it: The pcmcia reset line is not connected and after a reset/reboot
> the pcmcia card is in an undefined state and needs a manual reset.)
> This reset patch is probably useful to all Amiga pcmcia drivers (network and
> other) but since I do not own any other card I can't verify that.
>
> Signed-off-by: ALeX Kazik <alex@kazik.de>
> Tested-by: ALeX Kazik <alex@kazik.de>
>
> diff -urp linux-4.18.7/drivers/net/ethernet/8390/8390.h linux-4.18.7-patched/drivers/net/ethernet/8390/8390.h
> --- linux-4.18.7/drivers/net/ethernet/8390/8390.h 2018-09-09 10:32:43.000000000 +0200
> +++ linux-4.18.7-patched/drivers/net/ethernet/8390/8390.h 2018-09-15 14:51:00.000000000 +0200
> @@ -222,4 +222,21 @@ struct ei_device {
> #define ENTSR_CDH 0x40 /* The collision detect "heartbeat" signal was lost. */
> #define ENTSR_OWC 0x80 /* There was an out-of-window collision. */
>
> +/* Change the driver to support word access instead of byte access.
> + * Cards that work with byte access will not work with word access.
> + */
> +#ifdef CONFIG_APNE100MBIT
> +/* redefine inb to do word accesses */
> +#undef inb
> +#define inb(x) ((x) & 1 ? inw((x) - 1) & 0xff : inw(x) >> 8)
> +#undef inb_p
> +#define inb_p(x) inb(x)
> +
> +/* The following redefinition of outb isn't necessary, but may be faster on
> + * slow processors.
> + */
> +#undef outb
> +#define outb(x, y) raw_outb(x, (y) + GAYLE_IO + (((y) & 1) ? GAYLE_ODD : 0))
> +#endif
> +
> #endif /* _8390_h */
> Only in linux-4.18.7-patched/drivers/net/ethernet/8390/: 8390.h.orig
> diff -urp linux-4.18.7/drivers/net/ethernet/8390/Kconfig linux-4.18.7-patched/drivers/net/ethernet/8390/Kconfig
> --- linux-4.18.7/drivers/net/ethernet/8390/Kconfig 2018-09-09 10:32:43.000000000 +0200
> +++ linux-4.18.7-patched/drivers/net/ethernet/8390/Kconfig 2018-09-15 14:34:18.000000000 +0200
> @@ -142,6 +142,22 @@ config APNE
> To compile this driver as a module, choose M here: the module
> will be called apne.
>
> +if APNE
> +config APNE100MBIT
> + bool "PCMCIA NE2000 100MBit support"
> + default n
> + depends on ARM_ETHERH=n && AX88796=n && HYDRA=n && MAC8390=n
> + depends on MCF8390=n && NE2000=n && NE2K_PCI=n && PCMCIA_AXNET=n
> + depends on PCMCIA_PCNET=n && STNIC=n && ULTRA=n && WD80x3=n
> + depends on XSURF100=n && ZORRO8390=n
ARM_ETHERH and MCF8390 can't be configured along with APNE, so these are
safe to leave out here.
AX88796, HYDRA, MAC8390, XSURF100 and ZORRO8390 all use the lib8390.c
core, and define ei_inb() to use MMIO type access macros such as
read_8(). These won't be affected at all by your redefinition of inb(),
and can also be left out of the above list.
I suspect NE2K_PCI can't be selected on m68k for lack of PCI support,
might also be safe to drop.
The rest looks fine to me!
Cheers,
Michael
> + ---help---
> + This changes the driver to support ONLY 10/100Mbit cards (e.g. Netgear
> + FA411, CNet Singlepoint).
> + Cards that worked with the original version won't with this version.
> +
> + Say N, unless you absolutely know what you are doing.
> +endif
> +
> config PCMCIA_PCNET
> tristate "NE2000 compatible PCMCIA support"
> depends on PCMCIA
> diff -urp linux-4.18.7/drivers/net/ethernet/8390/apne.c linux-4.18.7-patched/drivers/net/ethernet/8390/apne.c
> --- linux-4.18.7/drivers/net/ethernet/8390/apne.c 2018-09-09 10:32:43.000000000 +0200
> +++ linux-4.18.7-patched/drivers/net/ethernet/8390/apne.c 2018-09-15 14:48:27.000000000 +0200
> @@ -590,6 +590,16 @@ static int init_pcmcia(void)
> #endif
> u_long offset;
>
> +#ifdef CONFIG_APNE100MBIT
> + /* reset card (idea taken from CardReset by Artur Pogoda) */
> + {
> + u_char tmp = gayle.intreq;
> +
> + gayle.intreq = 0xff; mdelay(1);
> + gayle.intreq = tmp; mdelay(300);
> + }
> +#endif
> +
> pcmcia_reset();
> pcmcia_program_voltage(PCMCIA_0V);
> pcmcia_access_speed(PCMCIA_SPEED_250NS);
^ permalink raw reply
* RE: [PATCH] net: ethernet: remove redundant null pointer check before of_node_put
From: Andy Duan @ 2018-09-17 1:55 UTC (permalink / raw)
To: zhong jiang, davem@davemloft.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1537103622-63482-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com> Sent: 2018年9月16日 21:14
> of_node_put has taken the null pinter check into account. So it is safe to
> remove the duplicated check before of_node_put.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Acked-by: Fugang Duan <fugang.duan@nxp.com>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 2708297..67d6c9d 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2055,8 +2055,7 @@ static int fec_enet_mii_init(struct
> platform_device *pdev)
>
> node = of_get_child_by_name(pdev->dev.of_node, "mdio");
> err = of_mdiobus_register(fep->mii_bus, node);
> - if (node)
> - of_node_put(node);
> + of_node_put(node);
> if (err)
> goto err_out_free_mdiobus;
>
> --
> 1.7.12.4
^ permalink raw reply
* Re: [RFC PATCH iproute2-next] System specification health API
From: Andrew Lunn @ 2018-09-16 19:57 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jakub Kicinski, Eran Ben Elisha, netdev, Jiri Pirko,
Andy Gospodarek, Michael Chan, Simon Horman, Alexander Duyck,
Florian Fainelli, Tal Alon, Ariel Almog
In-Reply-To: <20180916122939.498f7e0f@xeon-e3>
> Why is this going under iproute rather than using one of the existing sensor API's.
> For example Intel NIC's have thermal sensors etc.
Hi Stephen
These are not that sort of sensors. This is part of the naming problem
here. It is not really to do with health, it is about exceptions and
bugs. And the sensors are more like timeouts and watchdogs.
It is clear that the current names lead to a lot of confusion. Maybe:
health -> exception
sensor -> condition
Andrew
^ permalink raw reply
* Re: [PATCH net-next v4 18/20] crypto: port ChaCha20 to Zinc
From: Martin Willi @ 2018-09-16 19:51 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: linux-kernel, netdev, linux-crypto, davem, gregkh, Samuel Neves,
Andy Lutomirski, Jean-Philippe Aumasson, Eric Biggers
In-Reply-To: <20180914162240.7925-19-Jason@zx2c4.com>
Hi Jason,
> Now that ChaCha20 is in Zinc, we can have the crypto API code simply
> call into it.
> delete mode 100644 arch/x86/crypto/chacha20-avx2-x86_64.S
> delete mode 100644 arch/x86/crypto/chacha20-ssse3-x86_64.S
I did some trivial benchmarking with tcrypt for the ChaCha20Poly1305
AEAD as used by IPsec. This is on a box with AVX2, which is probably
the configuration mostly used these days. With Zinc I get:
> testing speed of rfc7539esp(chacha20,poly1305) (rfc7539esp(chacha20-software,poly1305-software)) decryption
> test 0 (288 bit key, 16 byte blocks): 743510 operations in 1 seconds (11896160 bytes)
> test 1 (288 bit key, 64 byte blocks): 743190 operations in 1 seconds (47564160 bytes)
> test 2 (288 bit key, 256 byte blocks): 701461 operations in 1 seconds (179574016 bytes)
> test 3 (288 bit key, 512 byte blocks): 681567 operations in 1 seconds (348962304 bytes)
> test 4 (288 bit key, 1024 byte blocks): 572854 operations in 1 seconds (586602496 bytes)
> test 5 (288 bit key, 2048 byte blocks): 434477 operations in 1 seconds (889808896 bytes)
> test 6 (288 bit key, 4096 byte blocks): 293553 operations in 1 seconds (1202393088 bytes)
> test 7 (288 bit key, 8192 byte blocks): 173351 operations in 1 seconds (1420091392 bytes)
Using the existing implementation, this was:
> testing speed of rfc7539esp(chacha20,poly1305) (rfc7539esp(chacha20-simd,poly1305-simd)) decryption
> test 0 (288 bit key, 16 byte blocks): 1064524 operations in 1 seconds (17032384 bytes)
> test 1 (288 bit key, 64 byte blocks): 1016046 operations in 1 seconds (65026944 bytes)
> test 2 (288 bit key, 256 byte blocks): 829566 operations in 1 seconds (212368896 bytes)
> test 3 (288 bit key, 512 byte blocks): 778912 operations in 1 seconds (398802944 bytes)
> test 4 (288 bit key, 1024 byte blocks): 622331 operations in 1 seconds (637266944 bytes)
> test 5 (288 bit key, 2048 byte blocks): 441790 operations in 1 seconds (904785920 bytes)
> test 6 (288 bit key, 4096 byte blocks): 280616 operations in 1 seconds (1149403136 bytes)
> test 7 (288 bit key, 8192 byte blocks): 158800 operations in 1 seconds (1300889600 bytes)
I've also experimented with the SIMD context save/restore amortization
from patch one on the existing implementation:
> testing speed of rfc7539esp(chacha20,poly1305) (rfc7539esp(chacha20-simd,poly1305-simd)) decryption
> test 0 (288 bit key, 16 byte blocks): 1088215 operations in 1 seconds (17411440 bytes)
> test 1 (288 bit key, 64 byte blocks): 1001788 operations in 1 seconds (64114432 bytes)
> test 2 (288 bit key, 256 byte blocks): 870193 operations in 1 seconds (222769408 bytes)
> test 3 (288 bit key, 512 byte blocks): 822149 operations in 1 seconds (420940288 bytes)
> test 4 (288 bit key, 1024 byte blocks): 647447 operations in 1 seconds (662985728 bytes)
> test 5 (288 bit key, 2048 byte blocks): 454734 operations in 1 seconds (931295232 bytes)
> test 6 (288 bit key, 4096 byte blocks): 286995 operations in 1 seconds (1175531520 bytes)
> test 7 (288 bit key, 8192 byte blocks): 162028 operations in 1 seconds (1327333376 bytes)
For large blocks your implementation is faster; for typical IPsec MTUs
this degrades performance by ~10% and more.
Martin
^ permalink raw reply
* Re: [RFC PATCH iproute2-next] System specification health API
From: Stephen Hemminger @ 2018-09-16 19:29 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Eran Ben Elisha, netdev, Jiri Pirko, Andy Gospodarek,
Michael Chan, Simon Horman, Alexander Duyck, Andrew Lunn,
Florian Fainelli, Tal Alon, Ariel Almog
In-Reply-To: <20180913103604.0ef868f4@cakuba.netronome.com>
On Thu, 13 Sep 2018 10:36:04 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> On Thu, 13 Sep 2018 11:18:15 +0300, Eran Ben Elisha wrote:
> > The health spec is targeted for Real Time Alerting, in order to know when
> > something bad had happened to a PCI device
>
> By spec you mean some standards body spec you implement or this
> proposal is a spec?
>
> > - Provide alert debug information
> > - Self healing
> > - If problem needs vendor support, provide a way to gather all needed debugging
> > information.
> >
> > The health contains sensors which sense for malfunction. Once sensor triggered,
> > actions such as logs and correction can be taken.
> > Sensors are sensing the health state and can trigger correction action.
> >
> > The sensors are divided into the following groups
> > - Hardware sensor - a sensor which is triggered by the device due to
> > malfunction.
> > - Software sensor - a sensor which is triggered by the software due to
> > malfunction.
> > Both group of sensors can be triggered due to error event or due to a periodic check.
> >
> > Actions are the way to handle sensor events. Action can be in one of the
> > following groups:
> > - Dump - SW trace, SW dump, HW trace, HW dump
> > - Reset - Surgical correction (e.g. modify Q, flush Q, reset of device, etc)
> > Actions can be performed by SW or HW.
> >
> > User is allowed to enable or disable sensors and sensor2action mapping.
> >
> > This RFC man page patch describes the suggested API of devlink-health in order
> > to control sensors and actions.
>
> I like the idea of configuring response to events like this, although
> I'm not sure the name sensor is appropriate here - perhaps exception or
> error would be better? Are there going to be values reported?
>
> I'm not so sure about HW sensors in relation to existing HWMON
> infrastructure... I assume you're targeting things like say some HW
> engine/block reporting it encountered an error? Sounds good, too.
>
> Are the actions all envisioned to be performed by the driver?
> Firmware? Hardware? I guess that distinction can be added later.
> For FW/HW actions we would go back to the problem of persistence of
> the setting since it was only implemented for params :S
>
> Is the dump option going to tie back into region snapshots?
Why is this going under iproute rather than using one of the existing sensor API's.
For example Intel NIC's have thermal sensors etc.
^ permalink raw reply
* Re: [PATH RFC net-next 1/8] net: phy: Move linkmode helpers to somewhere public
From: Andrew Lunn @ 2018-09-16 19:18 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <a896ca76-d585-5f12-faca-e6ad5f386d4e@gmail.com>
> Good idea, I wonder if we should create a more specific directory within
> include/linux/ that can host a variety of PHYLIB, PHYLINK and what not
> header files, but this could be solved later on.
I'm leaving it for later.
We would also need to figure out a name for this directory. phy is
already used by the generic phy subsystem. So i guess we would have to
use something like ethernet-phy.
Andrew
^ permalink raw reply
* Re: [RFC PATCH 2/4] net: enable UDP gro on demand.
From: Willem de Bruijn @ 2018-09-16 18:23 UTC (permalink / raw)
To: Paolo Abeni
Cc: Network Development, David Miller, Willem de Bruijn,
steffen.klassert
In-Reply-To: <CAF=yD-JQtW7MW8UZHbNqB5zrYL+f4q1b1CiPnL0oy94_gopUcA@mail.gmail.com>
On Fri, Sep 14, 2018 at 1:16 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Fri, Sep 14, 2018 at 11:47 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >
> > Currently, the UDP GRO callback is always invoked, regardless of
> > the existence of any actual user (e.g. a UDP tunnel). With retpoline
> > enabled, this causes measurable overhead.
> >
> > This changeset introduces explicit accounting of the sockets requiring
> > UDP GRO and updates the UDP offloads at runtime accordingly, so that
> > the GRO callback is present (and invoked) only when there is at least
> > one socket requiring it.
>
> I have a difference solution both to the UDP socket lookup avoidance
> and configurable GRO in general.
>
> I've been sitting on it for too long. Let me slightly clean it up and
> send it out for discussion sake..
http://patchwork.ozlabs.org/project/netdev/list/?series=65763
That udp gro implementation is clearly less complete than yours in
this patchset. The point I wanted to bring up for discussion is not the
protocol implementation, but the infrastructure for enabling it
conditionally.
Assuming cycle cost is comparable, what do you think of using the
existing sk offload callbacks to enable this on a per-socket basis?
As for the protocol-wide knob, I do strongly prefer something that can
work for all protocols, not just UDP. I also implemented a version that
atomically swaps the struct ptr instead of the flag based approach I sent
for review. I'm fairly agnostic about that point. One subtle issue is that I
believe we need to keep the gro_complete callbacks enabled, as gro
packets may be queued for completion when gro_receive gets disabled.
^ 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