* Re: [Intel-wired-lan] [i40e] regression on TCP stream and TCP maerts, kernel-4.12.0-0.rc2
From: Duyck, Alexander H @ 2017-06-01 19:18 UTC (permalink / raw)
To: atomasov@redhat.com, alexander.duyck@gmail.com
Cc: osabart@redhat.com, netdev@vger.kernel.org, aokuliar@redhat.com,
intel-wired-lan@lists.osuosl.org, jhladky@redhat.com
In-Reply-To: <1496312080.3758.7.camel@redhat.com>
On Thu, 2017-06-01 at 12:14 +0200, Adrian Tomasov wrote:
> On Wed, 2017-05-31 at 14:42 -0700, Alexander Duyck wrote:
> >
> > On Wed, May 31, 2017 at 6:48 AM, Adrian Tomasov <atomasov@redhat.com>
> > wrote:
> > >
> > >
> > > On Tue, 2017-05-30 at 18:27 -0700, Alexander Duyck wrote:
> > > >
> > > >
> > > > On Tue, May 30, 2017 at 8:41 AM, Alexander Duyck
> > > > <alexander.duyck@gmail.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > > On Tue, May 30, 2017 at 6:43 AM, Adam Okuliar <aokuliar@redhat.
> > > > > com>
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > we found regression on intel card(XL710) with i40e driver.
> > > > > > Regression is
> > > > > > about ~45%
> > > > > > on TCP_STREAM and TCP_MAERTS test for IPv4 and IPv6.
> > > > > > Regression
> > > > > > was first
> > > > > > visible in kernel-4.12.0-0.rc1.
> > > > > >
> > > > > > More details about results you can see in uploaded images in
> > > > > > bugzilla. [0]
> > > > > >
> > > > > >
> > > > > > [0] https://bugzilla.kernel.org/show_bug.cgi?id=195923
> > > > > >
> > > > > >
> > > > > > Best regards, / S pozdravom,
> > > > > >
> > > > > > Adrián Tomašov
> > > > > > Kernel Performance QE
> > > > > > atomasov@redhat.com
> > > > >
> > > > > I have added the i40e driver maintainer and the intel-wired-lan
> > > > > mailing list so that we can make are developers aware of the
> > > > > issue.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > - Alex
> > > >
> > > > Adam,
> > > >
> > > > We are having some issues trying to reproduce what you reported.
> > > >
> > > > Can you provide some additional data. Specifically we would be
> > > > looking
> > > > for an "ethtool -i", and an "ethtool -S" for the port before and
> > > > after
> > > > the test. If you can attach it to the bugzilla that would be
> > > > appreciated.
> > > >
> > > > Thanks.
> > > >
> > > > - Alex
> > >
> > > Hello Alex,
> > >
> > > requested files are updated in bugzilla.
> > >
> > > If you have any questions about testing feel free to ask.
> > >
> > >
> > > Best regards,
> > >
> > > Adrian
> >
> > So looking at the data I wonder if we don't have an MTU mismatch in
> > the network config. I notice the "after" has rx_length_errors being
> > reported. Recent changes made it so that i40e doesn't support jumbo
> > frames by default, whereas before we could. You might want to check
> > for that as that could cause the kind of performance issues you are
> > seeing.
> >
> > - Alex
>
> There isn't MTU mismatch. Traffic path is : server -> switch ->
> server.
>
>
> Output from switch:
>
> > show interfaces et-0/0/18
> Physical interface: et-0/0/18, Enabled, Physical link is Up
> Interface index: 644, SNMP ifIndex: 538
> Link-level type: Ethernet, MTU: 1514, Speed: 40Gbps, BPDU Error:
> None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering:
> Disabled, Flow control: Disabled, Media type: Fiber
> Device flags : Present Running
> Interface flags: SNMP-Traps Internal: 0x4000
> Link flags : None
> CoS queues : 12 supported, 12 maximum usable queues
> Current address: d4:04:ff:90:5a:4b, Hardware address:
> d4:04:ff:90:5a:4b
> Last flapped : 2017-06-01 10:09:32 CEST (01:21:29 ago)
> Input rate : 432 bps (0 pps)
> Output rate : 8336 bps (11 pps)
> Active alarms : None
> Active defects : None
> Interface transmit statistics: Disabled
>
> Logical interface et-0/0/18.0 (Index 552) (SNMP ifIndex 539)
> Flags: SNMP-Traps 0x24024000 Encapsulation: Ethernet-Bridge
> Input packets : 464041
> Output packets: 209210
> Protocol eth-switch, MTU: 1514
> Flags: Is-Primary, Trunk-Mode
>
>
> MTU is same for all et-0/0/x interfaces.
>
> - Adrian
One thing you might try try doing is toggling the legacy-rx flag using
the "ethtool --show-priv-flags/--set-priv-flags" command to see if that
has any impact. That will help to rule things out as the most
significant change I can think of is the recent update of the Rx path
to support XDP.
Also one other thing you might try would be to use a fixed interrupt
moderation rate by locking things down using "ethtool -C" to disable
adaptive interrupt moderation and lock the Rx usecs and Tx usecs at
some predefined values. I seem to recall there have been some interrupt
moderation changes made recently that might be impacting the
performance.
Beyond that is there any chance you would be able to bisect the issue?
Unfortunately we haven't be able to reproduce it internally so anything
that would help us to narrow down the problem would be useful.
Thanks.
- Alex
^ permalink raw reply
* Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument
From: Kees Cook @ 2017-06-01 19:10 UTC (permalink / raw)
To: Djalal Harouni
Cc: Serge E. Hallyn, Rusty Russell, David S . Miller, Jessica Yu,
LKML, Network Development, linux-security-module,
kernel-hardening@lists.openwall.com, Andy Lutomirski,
Andrew Morton, James Morris, Paul Moore, Stephen Smalley,
Greg Kroah-Hartman, Tetsuo Handa, Ingo Molnar, Linux API,
Dongsu Park <dpar
In-Reply-To: <CAEiveUeKU-zxXUeeuTZ2Sf1NrbH+t9JjwaWOK_2varRDsfbEWg@mail.gmail.com>
On Thu, Jun 1, 2017 at 7:56 AM, Djalal Harouni <tixxdz@gmail.com> wrote:
> module_require_cap = 0;
>
> if (autoload == MODULES_AUTOLOAD_DISABLED)
> return -EPERM;
>
> if (autoload == MODULES_AUTOLOAD_PRIVILEGED || require_cap > 0) {
> if (prefix != NULL && *prefix != '\0')
> /*
> * Allow non-CAP_SYS_MODULE caps when
> * using a distinct prefix.
> */
> module_require_cap = require_cap;
> else
> /*
> * Otherwise always require CAP_SYS_MODULE if no
> * valid prefix. Callers that do not provide a valid prefix
> * should not provide a require_cap > 0
> */
> module_require_cap = CAP_SYS_MODULE;
> }
>
> /* If autoload allowed and 'module_require_cap' was *never* set, allow */
> if (module_require_cap == 0 && autoload == MODULES_AUTOLOAD_ALLOWED)
> return 0;
>
> return capable(module_require_cap) ? 0 : -EPERM;
>
> Maybe you will agree :-) ?
Yes! Looks good. I was accidentally still thinking about the caps
checks being in the net code, but obviously, that wouldn't be the case
anymore. Thanks for the catch. :)
> BTW Kees, also in next version I won't remove the
> capable(CAP_NET_ADMIN) check from [1]
> even if there is the new request_module_cap(), I would like it to be
> in a different patches, this way we go incremental
> and maybe it is better to merge what we have now ? and follow up
> later, and of course if other maintainers agree too!
Yes, incremental. I would suggest first creating the API changes to
move a basic require_cap test into the LSM (which would drop the
open-coded capable() checks in the net code), and then add the
autoload logic in the following patches. That way the "infrastructure"
changes happen separately and do not change any behaviors, but moves
the caps test down where its wanted in the LSM, before then augmenting
the logic.
> I just need a bit of free time to check again everything and will send
> a v5 with all requested changes.
Great, thank you!
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: [PATCH net] vxlan: eliminate cached dst leak
From: Lance Richardson @ 2017-06-01 19:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, pabeni
In-Reply-To: <20170601.144648.1946518537495893731.davem@davemloft.net>
> From: "David Miller" <davem@davemloft.net>
> To: lrichard@redhat.com
> Cc: netdev@vger.kernel.org, pabeni@redhat.com
> Sent: Thursday, 1 June, 2017 2:46:48 PM
> Subject: Re: [PATCH net] vxlan: eliminate cached dst leak
>
> From: Lance Richardson <lrichard@redhat.com>
> Date: Mon, 29 May 2017 13:25:57 -0400
>
> > After commit 0c1d70af924b ("net: use dst_cache for vxlan device"),
> > cached dst entries could be leaked when more than one remote was
> > present for a given vxlan_fdb entry, causing subsequent netns
> > operations to block indefinitely and "unregister_netdevice: waiting
> > for lo to become free." messages to appear in the kernel log.
> >
> > Fix by properly releasing cached dst and freeing resources in this
> > case.
> >
> > Fixes: commit 0c1d70af924b ("net: use dst_cache for vxlan device")
>
> In the future please do not put that "commit " string there, it's not
> needed.
Oops, sorry about that, I know I've made that mistake before (both times
because a checkpatch.pl warning in the body made me think I needed to
change the Fixes: tag as well). Now I'm tempted to roll a checkpatch.pl
improvement...
>
> > Signed-off-by: Lance Richardson <lrichard@redhat.com>
>
> Applied and queued up for -stable, thank you.
>
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: spectrum: Add bridge dependency for spectrum
From: David Miller @ 2017-06-01 19:07 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, nikolay, mlxsw, arnd
In-Reply-To: <20170531183342.19349-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Wed, 31 May 2017 21:33:42 +0300
> When BRIDGE is a loadable module, MLXSW_SPECTRUM mustn't be built-in:
>
> drivers/built-in.o: In function `mlxsw_sp_bridge_device_create':
> drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c:145: undefined reference to `br_vlan_enabled'
> drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c:158: undefined reference to `br_multicast_enabled'
> drivers/built-in.o: In function `mlxsw_sp_dev_rif_type':
> drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:2972: undefined reference to `br_vlan_enabled'
> drivers/built-in.o: In function `mlxsw_sp_inetaddr_vlan_event':
> drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3310: undefined reference to `br_vlan_enabled'
>
> Add Kconfig dependency to enforce usable configurations.
>
> Fixes: c57529e1d5d8 ("mlxsw: spectrum: Replace vPorts with Port-VLAN")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Reported-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> Tested-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] ARM: imx6ul-14x14-evk: Fix suspend over nfs by phy
From: David Miller @ 2017-06-01 19:03 UTC (permalink / raw)
To: leonard.crestez
Cc: f.fainelli, andrew, shawnguo, fugang.duan, johan,
alexandre.belloni, p.zabel, fabio.estevam, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1496224930.git.leonard.crestez@nxp.com>
From: Leonard Crestez <leonard.crestez@nxp.com>
Date: Wed, 31 May 2017 13:29:28 +0300
> Right now attempting doing suspend/resume while root is mounted over NFS
> hangs on imx6ul-14x14-evk. This is happening because ksz8081 phy fixups are
> lost on resume.
>
> Fix this by using equivalent devicetree properties instead of a phy fixup
> and handling those properties on resume in the micrel driver.
>
> In theory it might now be possible to remove the phy fixup from mach-imx6ul
> entirely but it is possible that this would break other imx6ul boards which
> use the same phy. The solution would be to patch their dts but it's not
> clear how to identify affected boards.
>
> This code is shared with imx6ull-14x14-evk but 6ull suspend needs an
> unrelated patch: https://lkml.org/lkml/2017/5/30/584
>
> This is something of a corner case so there is no CC: stable.
>
> Changes since v1: https://lkml.org/lkml/2017/5/30/672
> * Split a kszphy_config_reset function for stuff shared between
> config_init and resume. Calling config_init directly could be an option but
> on some HW variants it does extra stuff like parsing devicetree options.
> That would not be appropriate for resume code.
Series applied.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/8] Introduce bpf ID
From: Jakub Kicinski @ 2017-06-01 19:00 UTC (permalink / raw)
To: David Ahern
Cc: Alexei Starovoitov, Martin KaFai Lau, Hannes Frederic Sowa,
netdev, Daniel Borkmann, kernel-team
In-Reply-To: <5e8b1713-0220-5c53-210d-8040efd36cfb@gmail.com>
On Thu, 1 Jun 2017 12:52:28 -0600, David Ahern wrote:
> On 6/1/17 12:27 PM, Alexei Starovoitov wrote:
> > 'I want to retrieve original instructions' is not a problem. It's a
> > push for 'solution'. Explaining 'why' you want to see original
> > instructions would describe the actual problem.
>
> I have explained this.
>
> You are creating this hyper-complex almost completely invisible
> infrastructure. You are enabling binary blobs that can bypass the
> network stack and modify packets with almost no introspection on what is
> happening. BPF code can from a variety of sources -- OS vendors,
> upstream repos, 3rd party vendors (eg., H/W vendors), and "in-house"
> development. Each will swear to the end that any observed problem is not
> with their code. In my experience, it falls on to the OS and kernel
> experts to figure out why Linux is breaking something. To do that we
> need tools to look at what code is running where and something that can
> be used in production environments not requiring a disruption to the
> service that the box is providing.
Forgive my ignorance, but is it possible to dump code of a loaded
module out of the kernel?
^ permalink raw reply
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
From: David Miller @ 2017-06-01 18:58 UTC (permalink / raw)
To: clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170531071852.12422-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Wed, 31 May 2017 09:18:31 +0200
> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> present on Allwinner H3/H5/A83T/A64 SoCs.
Series applied, but wow that's a lot of DT file changes :-(
^ permalink raw reply
* Re: [PATCH v2 net-next 0/8] Introduce bpf ID
From: Jakub Kicinski @ 2017-06-01 18:57 UTC (permalink / raw)
To: David Miller; +Cc: ast, dsahern, kafai, hannes, netdev, daniel, kernel-team
In-Reply-To: <20170601.143336.2263901633118099409.davem@davemloft.net>
On Thu, 01 Jun 2017 14:33:36 -0400 (EDT), David Miller wrote:
> From: Alexei Starovoitov <ast@fb.com>
> Date: Thu, 1 Jun 2017 11:27:56 -0700
>
> > Original instructions are not useful for debugging, since they have
> > map_fds which can be long gone when program is running, therefore to
> > solve introspection problem we need to look into real kernel
> > instructions.
>
> The only possible legitimate use I see for the original instructions
> is checkpoint/restart.
>
> If 6wind wants this for "external acceleration" or whatever, like
> Alexei I am not interested in facilitating that at all.
+1
I will try disabling the inlining then.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/8] Introduce bpf ID
From: David Miller @ 2017-06-01 18:56 UTC (permalink / raw)
To: dsahern; +Cc: ast, kubakici, kafai, hannes, netdev, daniel, kernel-team
In-Reply-To: <5e8b1713-0220-5c53-210d-8040efd36cfb@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Thu, 1 Jun 2017 12:52:28 -0600
> On 6/1/17 12:27 PM, Alexei Starovoitov wrote:
>> 'I want to retrieve original instructions' is not a problem. It's a
>> push for 'solution'. Explaining 'why' you want to see original
>> instructions would describe the actual problem.
>
> I have explained this.
>
> You are creating this hyper-complex almost completely invisible
> infrastructure. You are enabling binary blobs that can bypass the
> network stack and modify packets with almost no introspection on what is
> happening. BPF code can from a variety of sources -- OS vendors,
> upstream repos, 3rd party vendors (eg., H/W vendors), and "in-house"
> development. Each will swear to the end that any observed problem is not
> with their code. In my experience, it falls on to the OS and kernel
> experts to figure out why Linux is breaking something. To do that we
> need tools to look at what code is running where and something that can
> be used in production environments not requiring a disruption to the
> service that the box is providing.
I'm not convinced that the verifier processed instruction stream
cannot provide that facility properly.
In fact, because of how the maps and tail calls work, you can only
figure out what is really executing by looking at the final processed
instruction stream.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/8] Introduce bpf ID
From: David Ahern @ 2017-06-01 18:52 UTC (permalink / raw)
To: Alexei Starovoitov, Jakub Kicinski, Martin KaFai Lau,
Hannes Frederic Sowa
Cc: netdev, Daniel Borkmann, kernel-team
In-Reply-To: <cae83d5f-85ea-4c16-5f6b-2b71f0768b05@fb.com>
On 6/1/17 12:27 PM, Alexei Starovoitov wrote:
> 'I want to retrieve original instructions' is not a problem. It's a
> push for 'solution'. Explaining 'why' you want to see original
> instructions would describe the actual problem.
I have explained this.
You are creating this hyper-complex almost completely invisible
infrastructure. You are enabling binary blobs that can bypass the
network stack and modify packets with almost no introspection on what is
happening. BPF code can from a variety of sources -- OS vendors,
upstream repos, 3rd party vendors (eg., H/W vendors), and "in-house"
development. Each will swear to the end that any observed problem is not
with their code. In my experience, it falls on to the OS and kernel
experts to figure out why Linux is breaking something. To do that we
need tools to look at what code is running where and something that can
be used in production environments not requiring a disruption to the
service that the box is providing.
^ permalink raw reply
* Re: [PATCH] mISDN: Fix a sleep-in-atomic bug
From: David Miller @ 2017-06-01 18:50 UTC (permalink / raw)
To: baijiaju1990
Cc: isdn, mingo, fweisbec, geliangtang, akpm, yamada.masahiro, netdev,
linux-kernel
In-Reply-To: <1496214505-15155-1-git-send-email-baijiaju1990@163.com>
From: Jia-Ju Bai <baijiaju1990@163.com>
Date: Wed, 31 May 2017 15:08:25 +0800
> The driver may sleep under a read spin lock, and the function call path is:
> send_socklist (acquire the lock by read_lock)
> skb_copy(GFP_KERNEL) --> may sleep
>
> To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
Just proves that nobody has ever run this code with lock debugging
enabled, if at all.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] powerpc: use asm-generic/socket.h as much as possible
From: David Miller @ 2017-06-01 18:48 UTC (permalink / raw)
To: sfr; +Cc: netdev, mpe, benh, linuxppc-dev, arnd
In-Reply-To: <20170531154337.04ebcb75@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 31 May 2017 15:43:37 +1000
> asm-generic/socket.h already has an exception for the differences that
> powerpc needs, so just include it after defining the differences.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/powerpc/include/uapi/asm/socket.h | 92 +---------------------------------
> 1 file changed, 1 insertion(+), 91 deletions(-)
>
> Build tested using powerpc allyesconfig, pseries_le_defconfig, 32 bit
> and 64 bit allnoconfig and ppc44x_defconfig builds.
>
> Dave, this is on top of the net-next tree and I am sending it to you
> since it would produce a conflict if it was merged via the powerpc tree.
Ok, I applied this to net-next, thanks Stephen!
^ permalink raw reply
* Re: [PATCH net] vxlan: eliminate cached dst leak
From: David Miller @ 2017-06-01 18:46 UTC (permalink / raw)
To: lrichard; +Cc: netdev, pabeni
In-Reply-To: <20170529172557.7065-1-lrichard@redhat.com>
From: Lance Richardson <lrichard@redhat.com>
Date: Mon, 29 May 2017 13:25:57 -0400
> After commit 0c1d70af924b ("net: use dst_cache for vxlan device"),
> cached dst entries could be leaked when more than one remote was
> present for a given vxlan_fdb entry, causing subsequent netns
> operations to block indefinitely and "unregister_netdevice: waiting
> for lo to become free." messages to appear in the kernel log.
>
> Fix by properly releasing cached dst and freeing resources in this
> case.
>
> Fixes: commit 0c1d70af924b ("net: use dst_cache for vxlan device")
In the future please do not put that "commit " string there, it's not
needed.
> Signed-off-by: Lance Richardson <lrichard@redhat.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* [PATCH net-next V2 2/4] net/sched: cls_flower: add support for matching on ip tos and ttl
From: Or Gerlitz @ 2017-06-01 18:37 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Saeed Mahameed, Roi Dayan, Paul Blakey, Or Gerlitz
In-Reply-To: <1496342260-28199-1-git-send-email-ogerlitz@mellanox.com>
Benefit from the support of ip header fields dissection and
allow users to set rules matching on ipv4 tos and ttl or
ipv6 traffic-class and hoplimit.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
---
include/uapi/linux/pkt_cls.h | 5 +++++
net/sched/cls_flower.c | 39 +++++++++++++++++++++++++++++++++++++--
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index c6e8cf5..edf43dd 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -454,6 +454,11 @@ enum {
TCA_FLOWER_KEY_TCP_FLAGS, /* be16 */
TCA_FLOWER_KEY_TCP_FLAGS_MASK, /* be16 */
+ TCA_FLOWER_KEY_IP_TOS, /* u8 */
+ TCA_FLOWER_KEY_IP_TOS_MASK, /* u8 */
+ TCA_FLOWER_KEY_IP_TTL, /* u8 */
+ TCA_FLOWER_KEY_IP_TTL_MASK, /* u8 */
+
__TCA_FLOWER_MAX,
};
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index fb74a47..33feaee 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -50,6 +50,7 @@ struct fl_flow_key {
struct flow_dissector_key_ports enc_tp;
struct flow_dissector_key_mpls mpls;
struct flow_dissector_key_tcp tcp;
+ struct flow_dissector_key_ip ip;
} __aligned(BITS_PER_LONG / 8); /* Ensure that we can do comparisons as longs. */
struct fl_flow_mask_range {
@@ -427,6 +428,10 @@ static const struct nla_policy fl_policy[TCA_FLOWER_MAX + 1] = {
[TCA_FLOWER_KEY_MPLS_LABEL] = { .type = NLA_U32 },
[TCA_FLOWER_KEY_TCP_FLAGS] = { .type = NLA_U16 },
[TCA_FLOWER_KEY_TCP_FLAGS_MASK] = { .type = NLA_U16 },
+ [TCA_FLOWER_KEY_IP_TOS] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_IP_TOS_MASK] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_IP_TTL] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_IP_TTL_MASK] = { .type = NLA_U8 },
};
static void fl_set_key_val(struct nlattr **tb,
@@ -528,6 +533,19 @@ static int fl_set_key_flags(struct nlattr **tb,
return 0;
}
+static void fl_set_key_ip(struct nlattr **tb,
+ struct flow_dissector_key_ip *key,
+ struct flow_dissector_key_ip *mask)
+{
+ fl_set_key_val(tb, &key->tos, TCA_FLOWER_KEY_IP_TOS,
+ &mask->tos, TCA_FLOWER_KEY_IP_TOS_MASK,
+ sizeof(key->tos));
+
+ fl_set_key_val(tb, &key->ttl, TCA_FLOWER_KEY_IP_TTL,
+ &mask->ttl, TCA_FLOWER_KEY_IP_TTL_MASK,
+ sizeof(key->ttl));
+}
+
static int fl_set_key(struct net *net, struct nlattr **tb,
struct fl_flow_key *key, struct fl_flow_key *mask)
{
@@ -570,6 +588,7 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
fl_set_key_val(tb, &key->basic.ip_proto, TCA_FLOWER_KEY_IP_PROTO,
&mask->basic.ip_proto, TCA_FLOWER_UNSPEC,
sizeof(key->basic.ip_proto));
+ fl_set_key_ip(tb, &key->ip, &mask->ip);
}
if (tb[TCA_FLOWER_KEY_IPV4_SRC] || tb[TCA_FLOWER_KEY_IPV4_DST]) {
@@ -773,6 +792,8 @@ static void fl_init_dissector(struct cls_fl_head *head,
FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
FLOW_DISSECTOR_KEY_PORTS, tp);
FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
+ FLOW_DISSECTOR_KEY_IP, ip);
+ FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
FLOW_DISSECTOR_KEY_TCP, tcp);
FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
FLOW_DISSECTOR_KEY_ICMP, icmp);
@@ -1082,6 +1103,19 @@ static int fl_dump_key_mpls(struct sk_buff *skb,
return 0;
}
+static int fl_dump_key_ip(struct sk_buff *skb,
+ struct flow_dissector_key_ip *key,
+ struct flow_dissector_key_ip *mask)
+{
+ if (fl_dump_key_val(skb, &key->tos, TCA_FLOWER_KEY_IP_TOS, &mask->tos,
+ TCA_FLOWER_KEY_IP_TOS_MASK, sizeof(key->tos)) ||
+ fl_dump_key_val(skb, &key->ttl, TCA_FLOWER_KEY_IP_TTL, &mask->ttl,
+ TCA_FLOWER_KEY_IP_TTL_MASK, sizeof(key->ttl)))
+ return -1;
+
+ return 0;
+}
+
static int fl_dump_key_vlan(struct sk_buff *skb,
struct flow_dissector_key_vlan *vlan_key,
struct flow_dissector_key_vlan *vlan_mask)
@@ -1195,9 +1229,10 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
if ((key->basic.n_proto == htons(ETH_P_IP) ||
key->basic.n_proto == htons(ETH_P_IPV6)) &&
- fl_dump_key_val(skb, &key->basic.ip_proto, TCA_FLOWER_KEY_IP_PROTO,
+ (fl_dump_key_val(skb, &key->basic.ip_proto, TCA_FLOWER_KEY_IP_PROTO,
&mask->basic.ip_proto, TCA_FLOWER_UNSPEC,
- sizeof(key->basic.ip_proto)))
+ sizeof(key->basic.ip_proto)) ||
+ fl_dump_key_ip(skb, &key->ip, &mask->ip)))
goto nla_put_failure;
if (key->control.addr_type == FLOW_DISSECTOR_KEY_IPV4_ADDRS &&
--
2.3.7
^ permalink raw reply related
* [PATCH net-next V2 4/4] net/mlx5e: Offload TC matching on ip tos / traffic-class
From: Or Gerlitz @ 2017-06-01 18:37 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Saeed Mahameed, Roi Dayan, Paul Blakey, Or Gerlitz
In-Reply-To: <1496342260-28199-1-git-send-email-ogerlitz@mellanox.com>
Enable offloading of TC matching on ipv4 tos or ipv6 traffic-class.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 26 ++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 066045b..8ec13f9 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -582,7 +582,8 @@ static int __parse_cls_flower(struct mlx5e_priv *priv,
BIT(FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS) |
BIT(FLOW_DISSECTOR_KEY_ENC_PORTS) |
BIT(FLOW_DISSECTOR_KEY_ENC_CONTROL) |
- BIT(FLOW_DISSECTOR_KEY_TCP))) {
+ BIT(FLOW_DISSECTOR_KEY_TCP) |
+ BIT(FLOW_DISSECTOR_KEY_IP))) {
netdev_warn(priv->netdev, "Unsupported key used: 0x%x\n",
f->dissector->used_keys);
return -EOPNOTSUPP;
@@ -809,6 +810,29 @@ static int __parse_cls_flower(struct mlx5e_priv *priv,
*min_inline = MLX5_INLINE_MODE_TCP_UDP;
}
+ if (dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_IP)) {
+ struct flow_dissector_key_ip *key =
+ skb_flow_dissector_target(f->dissector,
+ FLOW_DISSECTOR_KEY_IP,
+ f->key);
+ struct flow_dissector_key_ip *mask =
+ skb_flow_dissector_target(f->dissector,
+ FLOW_DISSECTOR_KEY_IP,
+ f->mask);
+
+ MLX5_SET(fte_match_set_lyr_2_4, headers_c, ip_ecn, mask->tos & 0x3);
+ MLX5_SET(fte_match_set_lyr_2_4, headers_v, ip_ecn, key->tos & 0x3);
+
+ MLX5_SET(fte_match_set_lyr_2_4, headers_c, ip_dscp, mask->tos >> 2);
+ MLX5_SET(fte_match_set_lyr_2_4, headers_v, ip_dscp, key->tos >> 2);
+
+ if (mask->tos)
+ *min_inline = MLX5_INLINE_MODE_IP;
+
+ if (mask->ttl) /* currently not supported */
+ return -EOPNOTSUPP;
+ }
+
if (dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_TCP)) {
struct flow_dissector_key_tcp *key =
skb_flow_dissector_target(f->dissector,
--
2.3.7
^ permalink raw reply related
* [PATCH net-next V2 1/4] net/flow_dissector: add support for dissection of misc ip header fields
From: Or Gerlitz @ 2017-06-01 18:37 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Saeed Mahameed, Roi Dayan, Paul Blakey, Or Gerlitz
In-Reply-To: <1496342260-28199-1-git-send-email-ogerlitz@mellanox.com>
Add support for dissection of ip tos and ttl and ipv6 traffic-class
and hoplimit. Both are dissected into the same struct.
Uses similar call to ip dissection function as with tcp, arp and others.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
---
include/net/flow_dissector.h | 11 +++++++++++
net/core/flow_dissector.c | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 51 insertions(+)
diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
index efe34eec..e2663e9 100644
--- a/include/net/flow_dissector.h
+++ b/include/net/flow_dissector.h
@@ -165,6 +165,16 @@ struct flow_dissector_key_tcp {
__be16 flags;
};
+/**
+ * struct flow_dissector_key_ip:
+ * @tos: tos
+ * @ttl: ttl
+ */
+struct flow_dissector_key_ip {
+ __u8 tos;
+ __u8 ttl;
+};
+
enum flow_dissector_key_id {
FLOW_DISSECTOR_KEY_CONTROL, /* struct flow_dissector_key_control */
FLOW_DISSECTOR_KEY_BASIC, /* struct flow_dissector_key_basic */
@@ -186,6 +196,7 @@ enum flow_dissector_key_id {
FLOW_DISSECTOR_KEY_ENC_PORTS, /* struct flow_dissector_key_ports */
FLOW_DISSECTOR_KEY_MPLS, /* struct flow_dissector_key_mpls */
FLOW_DISSECTOR_KEY_TCP, /* struct flow_dissector_key_tcp */
+ FLOW_DISSECTOR_KEY_IP, /* struct flow_dissector_key_ip */
FLOW_DISSECTOR_KEY_MAX,
};
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 5a45943..fc5fc45 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -367,6 +367,40 @@ __skb_flow_dissect_tcp(const struct sk_buff *skb,
key_tcp->flags = (*(__be16 *) &tcp_flag_word(th) & htons(0x0FFF));
}
+static void
+__skb_flow_dissect_ipv4(const struct sk_buff *skb,
+ struct flow_dissector *flow_dissector,
+ void *target_container, void *data, const struct iphdr *iph)
+{
+ struct flow_dissector_key_ip *key_ip;
+
+ if (!dissector_uses_key(flow_dissector, FLOW_DISSECTOR_KEY_IP))
+ return;
+
+ key_ip = skb_flow_dissector_target(flow_dissector,
+ FLOW_DISSECTOR_KEY_IP,
+ target_container);
+ key_ip->tos = iph->tos;
+ key_ip->ttl = iph->ttl;
+}
+
+static void
+__skb_flow_dissect_ipv6(const struct sk_buff *skb,
+ struct flow_dissector *flow_dissector,
+ void *target_container, void *data, const struct ipv6hdr *iph)
+{
+ struct flow_dissector_key_ip *key_ip;
+
+ if (!dissector_uses_key(flow_dissector, FLOW_DISSECTOR_KEY_IP))
+ return;
+
+ key_ip = skb_flow_dissector_target(flow_dissector,
+ FLOW_DISSECTOR_KEY_IP,
+ target_container);
+ key_ip->tos = ipv6_get_dsfield(iph);
+ key_ip->ttl = iph->hop_limit;
+}
+
/**
* __skb_flow_dissect - extract the flow_keys struct and return it
* @skb: sk_buff to extract the flow from, can be NULL if the rest are specified
@@ -469,6 +503,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
}
}
+ __skb_flow_dissect_ipv4(skb, flow_dissector,
+ target_container, data, iph);
+
if (flags & FLOW_DISSECTOR_F_STOP_AT_L3)
goto out_good;
@@ -514,6 +551,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
goto out_good;
}
+ __skb_flow_dissect_ipv6(skb, flow_dissector,
+ target_container, data, iph);
+
if (flags & FLOW_DISSECTOR_F_STOP_AT_L3)
goto out_good;
--
2.3.7
^ permalink raw reply related
* [PATCH net-next V2 0/4] add support for dissection and matching on ip tos and ttl
From: Or Gerlitz @ 2017-06-01 18:37 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Saeed Mahameed, Roi Dayan, Paul Blakey, Or Gerlitz
Hi Dave,
The 1st two patches enable matching/classifying on ip tos and ttl by
the flow dissector and flower. The other two patches offload matching
on tcp flags and ip tos in mlx5.
The mlx5 patches touch single file/function and not interfere with
other inflight mlx5 submissions.
Or.
V2: repost as asked by Dave.
Or Gerlitz (4):
net/flow_dissector: add support for dissection of misc ip header fields
net/sched: cls_flower: add support for matching on ip tos and ttl
net/mlx5e: Offload TC matching on tcp flags
net/mlx5e: Offload TC matching on ip tos / traffic-class
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 46 ++++++++++++++++++++++++-
include/net/flow_dissector.h | 11 ++++++
include/uapi/linux/pkt_cls.h | 5 +++
net/core/flow_dissector.c | 40 +++++++++++++++++++++
net/sched/cls_flower.c | 39 +++++++++++++++++++--
5 files changed, 138 insertions(+), 3 deletions(-)
--
2.3.7
^ permalink raw reply
* [PATCH net-next V2 3/4] net/mlx5e: Offload TC matching on tcp flags
From: Or Gerlitz @ 2017-06-01 18:37 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Saeed Mahameed, Roi Dayan, Paul Blakey, Or Gerlitz
In-Reply-To: <1496342260-28199-1-git-send-email-ogerlitz@mellanox.com>
Enable offloading of TC matching on tcp flags.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 7914a32..066045b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -581,7 +581,8 @@ static int __parse_cls_flower(struct mlx5e_priv *priv,
BIT(FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) |
BIT(FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS) |
BIT(FLOW_DISSECTOR_KEY_ENC_PORTS) |
- BIT(FLOW_DISSECTOR_KEY_ENC_CONTROL))) {
+ BIT(FLOW_DISSECTOR_KEY_ENC_CONTROL) |
+ BIT(FLOW_DISSECTOR_KEY_TCP))) {
netdev_warn(priv->netdev, "Unsupported key used: 0x%x\n",
f->dissector->used_keys);
return -EOPNOTSUPP;
@@ -808,6 +809,25 @@ static int __parse_cls_flower(struct mlx5e_priv *priv,
*min_inline = MLX5_INLINE_MODE_TCP_UDP;
}
+ if (dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_TCP)) {
+ struct flow_dissector_key_tcp *key =
+ skb_flow_dissector_target(f->dissector,
+ FLOW_DISSECTOR_KEY_TCP,
+ f->key);
+ struct flow_dissector_key_tcp *mask =
+ skb_flow_dissector_target(f->dissector,
+ FLOW_DISSECTOR_KEY_TCP,
+ f->mask);
+
+ MLX5_SET(fte_match_set_lyr_2_4, headers_c, tcp_flags,
+ ntohs(mask->flags));
+ MLX5_SET(fte_match_set_lyr_2_4, headers_v, tcp_flags,
+ ntohs(key->flags));
+
+ if (mask->flags)
+ *min_inline = MLX5_INLINE_MODE_TCP_UDP;
+ }
+
return 0;
}
--
2.3.7
^ permalink raw reply related
* Re: [PATCH v2 net-next 0/8] Introduce bpf ID
From: David Miller @ 2017-06-01 18:33 UTC (permalink / raw)
To: ast; +Cc: dsahern, kubakici, kafai, hannes, netdev, daniel, kernel-team
In-Reply-To: <cae83d5f-85ea-4c16-5f6b-2b71f0768b05@fb.com>
From: Alexei Starovoitov <ast@fb.com>
Date: Thu, 1 Jun 2017 11:27:56 -0700
> Original instructions are not useful for debugging, since they have
> map_fds which can be long gone when program is running, therefore to
> solve introspection problem we need to look into real kernel
> instructions.
The only possible legitimate use I see for the original instructions
is checkpoint/restart.
If 6wind wants this for "external acceleration" or whatever, like
Alexei I am not interested in facilitating that at all.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/8] Introduce bpf ID
From: Alexei Starovoitov @ 2017-06-01 18:27 UTC (permalink / raw)
To: David Ahern, Jakub Kicinski, Martin KaFai Lau,
Hannes Frederic Sowa
Cc: netdev, Daniel Borkmann, kernel-team
In-Reply-To: <18d3c571-7434-eaea-43dc-d237712309d1@gmail.com>
On 6/1/17 10:51 AM, David Ahern wrote:
> On 6/1/17 11:24 AM, Alexei Starovoitov wrote:
>>
>> what problem are we trying to solve?
>> If we don't agree on the problem, we won't be able to agree on the
>> solution.
>
> I want the ability to retrieve the BPF instructions pushed to the
> kernel. Not just for cgroups and VRF, but everywhere - cgroups, sockets,
> xdp, filters, etc. I have this stated many times, including to you at
> netconf in April. From that discussion and the discussion on the RFC
> patch I sent in February, I thought we had an agreement that saving the
> instructions was the first step.
>
> Quentin at 6wind has expressed a similar interest for cls_bpf and
> act_bpf code.
>
> I read Jakub's email as wanting the same but for XDP.
>
> The patches I referenced earlier save the original instructions and
> enable them to be read by userspace from an fd return by the bpf
> syscall. Combine that with the ID and we have a solution.
Please explain the problem instead of pushing for 'solution'.
In this case I do not see a problem that saving original instructions
will solve.
'I want to retrieve original instructions' is not a problem. It's a
push for 'solution'. Explaining 'why' you want to see original
instructions would describe the actual problem.
If you're trying to debug something you're interested in original
source code and in the instructions that kernel is running.
To correlate to source code we have prog_tag (that was computed
over original insns).
To see kernel instructions in the interpreter and JITed assembler
we have this set of patches.
Original instructions are not useful for debugging,
since they have map_fds which can be long gone when program
is running, therefore to solve introspection problem we need to
look into real kernel instructions.
My understanding that 6wind wants to see original instructions to
accelerate them somehow using out of tree technology.
I'm not interested to help that cause. I also suspect that
retrieving kernel instructions will not be much different from
that point of view, but at least returning kernel insns is
solving introspection problem for everyone.
Returning kernel insns also doesn't burn unnecessary memory,
whereas original insns will be there as dead weight.
Hence before we add them we need to be absolutely clear that
there is no cheaper alternative possible.
^ permalink raw reply
* RE: [PATCH iproute2] iplink: Update usage in help message
From: Eli Cohen @ 2017-06-01 18:06 UTC (permalink / raw)
To: Or Gerlitz, Tariq Toukan
Cc: Stephen Hemminger, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <CAJ3xEMh9qgGF9LbyNriPafiz3cgdiV8wQ9_A9Zbb4tU3oQ9agg@mail.gmail.com>
Sure, will do.
-----Original Message-----
From: Or Gerlitz [mailto:gerlitz.or@gmail.com]
Sent: Thursday, June 1, 2017 5:56 AM
To: Tariq Toukan <tariqt@mellanox.com>; Eli Cohen <eli@mellanox.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>; Linux Netdev List <netdev@vger.kernel.org>; Eran Ben Elisha <eranbe@mellanox.com>
Subject: Re: [PATCH iproute2] iplink: Update usage in help message
On Thu, Jun 1, 2017 at 11:00 AM, Tariq Toukan <tariqt@mellanox.com> wrote:
> From: Eli Cohen <eli@mellanox.com>
>
> Add to usage message a description of how to configure Infiniband node
> and port GUIDs.
>
> Fixes: d91fb3f4c7e4 ('Add support for configuring Infiniband GUIDs')
> Signed-off-by: Eli Cohen <eli@mellanox.com>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> ---
> ip/iplink.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/ip/iplink.c b/ip/iplink.c index
> da3f9a779351..ea112f71befc 100644
> --- a/ip/iplink.c
> +++ b/ip/iplink.c
> @@ -91,6 +91,8 @@ void iplink_usage(void)
> " [ query_rss { on | off} ]\n"
> " [ state { auto | enable | disable} ] ]\n"
> " [ trust { on | off} ] ]\n"
> + " [ node_guid { eui64 } ]\n"
> + " [ port_guid { eui64 } ]\n"
> " [ xdp { off |\n"
> " object FILE [ section NAME ] [ verbose ] |\n"
> " pinned FILE } ]\n"
Eli,
I see now that your original patch touched the man page but the word infiniband isn't mentioned:
@@ -1196,6 +1200,12 @@ sent by the VF.
.BI trust " on|off"
- trust the specified VF user. This enables that VF user can set a specific feature which may impact security and/or performance. (e.g. VF multicast promiscuous mode)
+.sp
+.BI node_guid " eui64"
+- configure node GUID for the VF.
+.sp
+.BI port_guid " eui64"
+- configure port GUID for the VF.
would be good if you enhance this patch to spell something like
configure node GUID for infiniband VFs.
configure port GUID for infiniband VFs.
Or.
^ permalink raw reply
* Re: [PATCH 5/5] net: phy: add Marvell Alaska X 88X3310 10Gigabit PHY support
From: Russell King - ARM Linux @ 2017-06-01 17:57 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, netdev
In-Reply-To: <ddf5b409-43fb-5045-ebfc-9a20d1ca1aec@gmail.com>
On Thu, Jun 01, 2017 at 10:28:04AM -0700, Florian Fainelli wrote:
> On 06/01/2017 03:26 AM, Russell King wrote:
> > Add phylib support for the Marvell Alaska X 10 Gigabit PHY (MV88X3310).
> > This phy is able to operate at 10G, 1G, 100M and 10M speeds, and only
> > supports Clause 45 accesses.
> >
> > The PHY appears (based on the vendor IDs) to be two different vendors
> > IP, with each devad containing several instances.
> >
> > This PHY driver has only been tested with the RJ45 copper port, fiber
> > port and a Marvell Armada 8040-based ethernet interface.
> >
> > It should be noted that to use the full range of speeds, MAC drivers
> > need to also reconfigure the link mode as per phydev->interface, since
> > the PHY automatically changes its interface mode depending on the
> > negotiated speed.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
>
> > MARVELL MVNETA ETHERNET DRIVER
> > M: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > L: netdev@vger.kernel.org
> > diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> > index 19eddf758c88..905990fece28 100644
> > --- a/drivers/net/phy/Makefile
> > +++ b/drivers/net/phy/Makefile
> > @@ -55,7 +55,7 @@ obj-$(CONFIG_ICPLUS_PHY) += icplus.o
> > obj-$(CONFIG_INTEL_XWAY_PHY) += intel-xway.o
> > obj-$(CONFIG_LSI_ET1011C_PHY) += et1011c.o
> > obj-$(CONFIG_LXT_PHY) += lxt.o
> > -obj-$(CONFIG_MARVELL_PHY) += marvell.o
> > +obj-$(CONFIG_MARVELL_PHY) += marvell.o marvell10g.o
>
> Could we introduce a CONFIG_MARVELL_10G_PHY symbol?
Thanks, I'll do that.
> > +enum {
> > + MV_PCS_BASE_T = 0x0000,
> > + MV_PCS_BASE_R = 0x1000,
> > + MV_PCS_1000BASEX = 0x2000,
> > +
> > + /* These registers appear at 0x800X and 0xa00X - the 0xa00X control
> > + * registers appear to set themselves to the 0x800X when AN is
> > + * restarted, but status registers appear readable from either.
> > + */
> > + MV_AN_CTRL1000 = 0x8000, /* 1000base-T control register */
> > + MV_AN_STAT1000 = 0x8001, /* 1000base-T status register */
> > +
> > + /* This register appears to reflect the copper status */
> > + MV_AN_RESULT = 0xa016,
> > + MV_AN_RESULT_SPD_10 = BIT(12),
> > + MV_AN_RESULT_SPD_100 = BIT(13),
> > + MV_AN_RESULT_SPD_1000 = BIT(14),
> > + MV_AN_RESULT_SPD_10000 = BIT(15),
> > +};
>
> Personal preference is not to use enums but jut plain #define, but
> whatever works, really.
I've come to prefer them as it avoids hiding them from the compiler
itself.
> > +
> > +static int mv3310_soft_reset(struct phy_device *phydev)
> > +{
> > + return 0;
> > +}
>
> You could use genphy_no_soft_reset(), although genphy sort of implies
> C22 now, or we could export genphy10g_soft_reset() which also does nothing.
The reason 88x3310 has no reset function is that setting the reset bit
appears to cause the PHY to become completely inaccessible over MDIO.
I'll add a comment here to that effect - but that would need the function
to remain here, otherwise the comment is rather lost amongst the code.
> > + /* Ethtool does not support the WAN mode bits */
> > + if (val & (MDIO_PMA_STAT2_10GBSR | MDIO_PMA_STAT2_10GBLR |
> > + MDIO_PMA_STAT2_10GBER | MDIO_PMA_STAT2_10GBLX4 |
> > + MDIO_PMA_STAT2_10GBSW | MDIO_PMA_STAT2_10GBLW |
> > + MDIO_PMA_STAT2_10GBEW))
> > + __set_bit(ETHTOOL_LINK_MODE_FIBRE_BIT, supported);
> > + if (val & MDIO_PMA_STAT2_10GBSR)
> > + __set_bit(ETHTOOL_LINK_MODE_10000baseSR_Full_BIT, supported);
> > + if (val & MDIO_PMA_STAT2_10GBLR)
> > + __set_bit(ETHTOOL_LINK_MODE_10000baseLR_Full_BIT, supported);
> > + if (val & MDIO_PMA_STAT2_10GBER)
> > + __set_bit(ETHTOOL_LINK_MODE_10000baseER_Full_BIT, supported);
> > +
> > + if (val & MDIO_PMA_STAT2_EXTABLE) {
> > + val = phy_read_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_PMA_EXTABLE);
> > + if (val < 0)
> > + return val;
> > +
> > + if (val & (MDIO_PMA_EXTABLE_10GBT | MDIO_PMA_EXTABLE_1000BT |
> > + MDIO_PMA_EXTABLE_100BTX | MDIO_PMA_EXTABLE_10BT))
> > + __set_bit(ETHTOOL_LINK_MODE_TP_BIT, supported);
> > + if (val & MDIO_PMA_EXTABLE_10GBLRM)
> > + __set_bit(ETHTOOL_LINK_MODE_FIBRE_BIT, supported);
> > + if (val & (MDIO_PMA_EXTABLE_10GBKX4 | MDIO_PMA_EXTABLE_10GBKR |
> > + MDIO_PMA_EXTABLE_1000BKX))
> > + __set_bit(ETHTOOL_LINK_MODE_Backplane_BIT, supported);
> > + if (val & MDIO_PMA_EXTABLE_10GBLRM)
> > + __set_bit(ETHTOOL_LINK_MODE_10000baseLRM_Full_BIT,
> > + supported);
> > + if (val & MDIO_PMA_EXTABLE_10GBT)
> > + __set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
> > + supported);
> > + if (val & MDIO_PMA_EXTABLE_10GBKX4)
> > + __set_bit(ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT,
> > + supported);
> > + if (val & MDIO_PMA_EXTABLE_10GBKR)
> > + __set_bit(ETHTOOL_LINK_MODE_10000baseKR_Full_BIT,
> > + supported);
> > + if (val & MDIO_PMA_EXTABLE_1000BT)
> > + __set_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
> > + supported);
> > + if (val & MDIO_PMA_EXTABLE_1000BKX)
> > + __set_bit(ETHTOOL_LINK_MODE_1000baseKX_Full_BIT,
> > + supported);
> > + if (val & MDIO_PMA_EXTABLE_100BTX)
> > + __set_bit(ETHTOOL_LINK_MODE_100baseT_Full_BIT,
> > + supported);
> > + if (val & MDIO_PMA_EXTABLE_10BT)
> > + __set_bit(ETHTOOL_LINK_MODE_10baseT_Full_BIT,
> > + supported);
> > + }
> > +
> > + if (!ethtool_convert_link_mode_to_legacy_u32(&mask, supported))
> > + dev_warn(&phydev->mdio.dev,
> > + "PHY supports (%*pb) more modes than phylib supports, some modes not supported.\n",
> > + __ETHTOOL_LINK_MODE_MASK_NBITS, supported);
> > +
> > + phydev->supported &= mask;
> > + phydev->advertising &= phydev->supported;
>
> Is not this a candidate for being moved into drivers/net/phy/phy-10g.c?
> Past the phy interface mode check, the rest does not appear to be
> particularly Marvell specific here.
I'm not entirely sure. This is decoding what the PMA/PMD supports,
which may not be solely appropriate for a generic case. Clause 45
is full of different blocks, each advertising their own capabilities.
(Eg, see the highly modified mii-diag output below.) The blocks
that are in use for the copper connection shown are the first PMA 0:1,
first PCS 0:3, second PHYXS 0:4, first AN 0:7 (for copper side) and
third AN (for MAC facing side).
Eg, the PCS says it supports 10GbaseR, 10GbaseX and 40GbaseR, but
the PMA says it doesn't support any 40G modes.
So, I wouldn't like to push code into a generic file which isn't the
correct approach.
Does anyone have a view on how Clause 45 PHYs should be handled wrt
what ethtool modes they support? Do we (eg) need to scan all
implemented MMDs and come up with a common subset of features?
mii-diag.c:v2.11 3/21/2005 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Using the new SIOCGMIIPHY value on PHY 8 (BMCR 0x2040).
Using the specified MII PHY index 32768.
No MII transceiver present!.
Use '--force' to view the information anyway.
libmii.c:v2.11 2/28/2005 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
MII PHY #0:1 transceiver registers:
2040 0006 002b 09aa 0071 009a c000 0009
9301 0000 0000 01a4 0000 0000 002b 09aa
0000 0000 0000 0000 0000 0003 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:0a:c2:--:--:--, model 26 rev. 10.
Vendor/Part: Marvell Semiconductor 88x3310.
PMA/PMD Control 1 register 2040: Speed determined by auto-negotiation.
PMA/PMD Status register 0006 ... 0006.
Receive link status: established.
PMA/PMD Speed capability 0071: 10G, 100M, 10M, 10G/1G, 10G.
PMA/PMD Control 2 register 0009: Type determined by auto-negotiation.
PMA/PMD Status 2 register 9301 ... 9301
Abilities: Local loopback, Transmit disable, Receive fault.
PMA/PMD Extended Ability register 01a4
Abilities: 10GBASE-T, 1000BASE-T, 100BASE-TX, 10BASE-T.
Pair swap 0003: MDI no crossover, A normal, B normal, C normal, D normal.
TX backoff b400: LP TX backoff 10dB TX backoff 10dB.
Operating SNR: A: 7.8dB B: 2.2dB C: 4.5dB D: 4.4dB.
Minimum SNR : A: 7.8dB B: 2.2dB C: 4.5dB D: 4.4dB.
Skew A>B -75.00ns A>C -80.00ns A>D -80.00ns
Fast retrain 0012.
MII PHY #0:3 transceiver registers:
2040 0006 002b 09aa 0001 009a c000 0003
8008 0000 0000 0000 0000 0000 002b 09aa
0000 0000 0000 0000 000e 0003 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
1001 8000 0000 0000 0000 0000 0000 0000
0000 0be3 0b83 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:0a:c2:--:--:--, model 26 rev. 10.
Vendor/Part: Marvell Semiconductor 88x3310.
PCS Control 1 register 2040: Speed 10Gb/s.
PCS Status register 0006 ... 0006.
Receive link status: established.
PCS Speed capability 0001: 10G.
PCS Control 2 register 0003: Type 10GBASE-T.
PCS Status 2 register 8008 ... 8008
Abilities: 10GBASE-T.
PCS BASE-R or 10GBASE-T status 1001 8000
PCS receive link up
Block lock
Block lock (latched).
MII PHY #0:3 Subdevice #2 transceiver registers
2040 0082 002b 09aa 0005 009e c000 0000
8c13 0000 0000 0000 0000 0000 002b 09aa
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
000c 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:0a:c2:--:--:--, model 26 rev. 10.
Vendor/Part: Marvell Semiconductor 88x3310.
PCS Control 1 register 2040: Speed 10Gb/s.
PCS Status register 0082 ... 0082.
Receive link status: not established.
*Fault condition detected*
PCS Speed capability 0005: 10G, 40G.
PCS Control 2 register 0000: Type 10GBASE-R.
PCS Status 2 register 8c13 ... 8c13
Abilities: 10GBASE-R, 10GBASE-X, 40GBASE-R.
*Transmit fault reported*.
*Receive fault reported*.
PCS BASE-R or 10GBASE-T status 000c 0000
PRBS9 pattern testing
PRBS31 pattern testing.
MII PHY #0:3 Subdevice #3 transceiver registers
1140 0149 0141 0daa 0020 0000 0004 2001
0000 0000 0000 0000 0000 0000 0000 8000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
000c 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:50:43:--:--:--, model 26 rev. 10.
Vendor/Part: Marvell Semiconductor 88x3310.
Basic mode control register 1140: Auto-negotiation enabled.
Basic mode status register 0149 ... 0149.
With extended status register 8000.
Link status: not established.
Capable of 1000baseX-FD.
Able to perform Auto-negotiation, negotiation not complete.
I'm advertising 0020: 1000baseX-FD.
MII PHY #0:4 transceiver registers:
2040 0082 0141 0daa 0001 001a 4000 0001
8403 0000 0000 0000 0000 0000 0141 0daa
0000 0000 0000 0000 0000 0000 0000 0000
0c00 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:50:43:--:--:--, model 26 rev. 10.
Vendor/Part: Marvell Semiconductor 88x3310.
PHYXS Control 1 register 2040: Speed 10Gb/s.
PHYXS Status register 0082 ... 0082.
Receive link status: not established.
*Fault condition detected*
PHYXS Speed capability 0001: 10G.
MII PHY #0:4 Subdevice #2 transceiver registers
2040 0006 002b 09aa 0005 009e c000 0000
8013 0000 0000 0000 0000 0000 002b 09aa
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
100d 8000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:0a:c2:--:--:--, model 26 rev. 10.
Vendor/Part: Marvell Semiconductor 88x3310.
PHYXS Control 1 register 2040: Speed 10Gb/s.
PHYXS Status register 0006 ... 0006.
Receive link status: established.
PHYXS Speed capability 0005: 10G.
MII PHY #0:4 Subdevice #3 transceiver registers
1140 0149 0141 0daa 0020 0000 0004 2001
0000 0000 0000 0000 0000 0000 0000 8000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:50:43:--:--:--, model 26 rev. 10.
Vendor/Part: Marvell Semiconductor 88x3310.
Basic mode control register 1140: Auto-negotiation enabled.
Basic mode status register 0149 ... 0149.
With extended status register 8000.
Link status: not established.
Capable of 1000baseX-FD.
Able to perform Auto-negotiation, negotiation not complete.
SGMII Link status 0020: Link down, reserved bits are set
SGMII MAC acknowledgement 0000:
MII PHY #0:7 transceiver registers:
3000 00ad 002b 09aa 0000 009a c000 0000
0000 0000 0000 0000 0000 0000 002b 09aa
1d41 0000 0000 dd41 0000 0000 2001 0000
0000 4c00 0003 0000 0000 0000 0000 0000
1181 7c60 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:0a:c2:--:--:--, model 26 rev. 10.
Vendor/Part: Marvell Semiconductor 88x3310.
AN Control 1 register 3000.
AN Status register 00ad ... 00ad.
Link status: established.
Able to perform Auto-negotiation, negotiation complete.
LP Auto-negotiation, Ext Next Pg.
I'm advertising 1d41 1181.
10Gbase-T AsymPause Pause 100baseTx-FD 10baseT-FD
I'm part of a single-port device.
LD loop timing.
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner advertisment is dd41.
Advertising AsymPause Pause 100baseTx-FD 10baseT-FD.
Negotiation completed.
XNP advert is 2001: message page 1
XNP link partner is 4c00: unformatted code 400
10GBASE-T status 7c60: Local PHY master LP 10GBASE-T LP loop timing.
MII PHY #0:7 Subdevice #2 transceiver registers
0000 000c 0141 0d90 0000 009e c000 0000
0000 0000 0000 0000 0000 0000 0141 0d90
0001 008d 0000 0000 0000 0000 2001 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0009 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:50:43:--:--:--, model 25 rev. 0.
Vendor/Part: Marvell Semiconductor (unknown).
AN Control 1 register 0000.
AN Status register 000c ... 000c.
Link status: established.
Able to perform Auto-negotiation, negotiation not complete.
I'm advertising 0000008d0001.
Advertising 10GBASE-KR.
IEEE 802.3 CSMA/CD protocol.
BASE-R Status: 10GBASE-KR.
MII PHY #0:7 Subdevice #3 transceiver registers
3000 00ad 0141 0c00 0000 008a 0000 0000
0000 0000 0000 0000 0000 0000 0141 0c00
1d41 0000 0000 dd41 0000 0000 2001 0000
0000 4c00 0003 0000 0000 0000 0000 0000
1181 4c60 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Vendor ID is 00:50:43:--:--:--, model 0 rev. 0.
Vendor/Part: Marvell Semiconductor (unknown).
AN Control 1 register 3000.
AN Status register 00ad ... 00ad.
Link status: established.
Able to perform Auto-negotiation, negotiation complete.
LP Auto-negotiation, Ext Next Pg.
I'm advertising 1d41 1181.
10Gbase-T AsymPause Pause 100baseTx-FD 10baseT-FD
I'm part of a single-port device.
LD loop timing.
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner advertisment is dd41.
Advertising AsymPause Pause 100baseTx-FD 10baseT-FD.
Negotiation completed.
XNP advert is 2001: message page 1
XNP link partner is 4c00: unformatted code 400
10GBASE-T status 4c60: Local PHY master Local RX not ok Remote RX not ok LP 10GBASE-T LP loop timing.
Other registers
8000: 0210 0b00 7973 0000 0404 0000 0000 800c
8008: 0000 1000 0000 0000 0101 2909 0000 0077
9000: 0010 014a 0000 0000 0000 0000 0000 0000
9008: 0000 0000 0000 0002 0001 0000 0000 0000
9800: 0010 014a 0000 0000 0000 0000 0000 0000
9808: 0000 0000 0000 0002 0001 0000 0000 0000
a000: 0210 0b00 7973 0000 0404 0000 0000 800c
a008: 0000 1000 0000 0000 0101 2909 2000 0010
a010: 0010 0000 0000 0000 0000 0000 8056 e009
a018: 402c 1803 0000 0000 0000 0000 0000 0000
a020: a400 0000 0000 0521 0200 0001 8521 0200
a028: 2901 8415 e02c 8000 1000 0000 0000 0000
a030: 073e 00fa 0000 0000 0000 0000 0000 0000
This produces:
root@mcbin:~# /shared/git/ethtool/build-arm64/ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Full
100baseT/Full
1000baseT/Full
10000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Full
100baseT/Full
1000baseT/Full
10000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Full
100baseT/Full
1000baseT/Full
10000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Speed: 10000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Link detected: yes
Note the lack of fiber modes - the PMA doesn't appear to be used for
fiber, and indicates that it doesn't support fiber.
So, with all this uncertainty, I'd rather not push the above block of
code as a generic helper just yet - at least not until we see more
10G PHYs, so we can get an idea of the correct direction for this.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/8] Introduce bpf ID
From: David Ahern @ 2017-06-01 17:51 UTC (permalink / raw)
To: Alexei Starovoitov, Jakub Kicinski, Martin KaFai Lau,
Hannes Frederic Sowa
Cc: netdev, Daniel Borkmann, kernel-team
In-Reply-To: <6ab73989-6246-ba15-7178-7863a110165c@fb.com>
On 6/1/17 11:24 AM, Alexei Starovoitov wrote:
>
> what problem are we trying to solve?
> If we don't agree on the problem, we won't be able to agree on the
> solution.
I want the ability to retrieve the BPF instructions pushed to the
kernel. Not just for cgroups and VRF, but everywhere - cgroups, sockets,
xdp, filters, etc. I have this stated many times, including to you at
netconf in April. From that discussion and the discussion on the RFC
patch I sent in February, I thought we had an agreement that saving the
instructions was the first step.
Quentin at 6wind has expressed a similar interest for cls_bpf and
act_bpf code.
I read Jakub's email as wanting the same but for XDP.
The patches I referenced earlier save the original instructions and
enable them to be read by userspace from an fd return by the bpf
syscall. Combine that with the ID and we have a solution.
^ permalink raw reply
* Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store
From: Larry Finger @ 2017-06-01 17:43 UTC (permalink / raw)
To: Jonathan Corbet, Jia-Ju Bai
Cc: kvalo, linux-wireless, b43-dev, netdev, linux-kernel
In-Reply-To: <20170601101113.6dd30d6d@lwn.net>
On 06/01/2017 11:11 AM, Jonathan Corbet wrote:
> On Thu, 01 Jun 2017 09:05:07 +0800
> Jia-Ju Bai <baijiaju1990@163.com> wrote:
>
>> I admit my patches are not well tested, and they may not well fix the bugs.
>> I am looking forward to opinions and suggestions :)
>
> May I politely suggest that sending out untested locking changes is a
> dangerous thing to do? You really should not be changing the locking in a
> piece of kernel code without understanding very well what the lock is
> protecting and being able to say why your changes are safe. Without that,
> the risk of introducing subtle bugs is very high.
>
> It looks like you have written a useful tool that could help us to make
> the kernel more robust. If you are interested in my suggestion, I would
> recommend that you post the sleep-in-atomic scenarios that you are
> finding, but refrain from "fixing" them in any case where you cannot offer
> a strong explanation of why your fix is correct.
>
> Thanks for working to find bugs in the kernel!
I agree with the suggestion above. Locking changes should only be done in
conjunction with testing by someone that actually has the hardware.
Larry
^ permalink raw reply
* Re: [PATCH 4/5] net: phy: add XAUI and 10GBASE-KR PHY connection types
From: Russell King - ARM Linux @ 2017-06-01 17:32 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Rob Herring, Mark Rutland,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <fb1a81e0-b5b9-80e4-7852-cc65a574b9e9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Jun 01, 2017 at 09:56:48AM -0700, Florian Fainelli wrote:
> On 06/01/2017 03:26 AM, Russell King wrote:
> > XAUI allows XGMII to reach an extended distance by using a XGXS layer at
> > each end of the MAC to PHY link, operating over four Serdes lanes.
> >
> > 10GBASE-KR is a single lane Serdes backplane ethernet connection method
> > with autonegotiation on the link. Some PHYs use this to connect to the
> > ethernet interface at 10G speeds, switching to other connection types
> > when utilising slower speeds.
> >
> > 10GBASE-KR is also used for XFI and SFI to connect to XFP and SFP fiber
> > modules.
> >
> > Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
>
> This looks good, but you also need to update
> Documentation/ABI/testing/sysfs-class-net-phydev since we report
> phy_interface from sysfs.
Hmm, seems to be a new file recently merged into net-next. Ok, I'll
provide an update for that.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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