27 Dec, 2019
10 commits
-
On RTL8211F the RX and TX delays (2ns) can be configured in two ways:
- pin strapping (RXD1 for the TX delay and RXD0 for the RX delay, LOW
means "off" and HIGH means "on") which is read during PHY reset
- using software to configure the TX and RX delay registersSo far only the configuration using pin strapping has been supported.
Add support for enabling or disabling the RGMII RX delay based on the
phy-mode to be able to get the RX delay into a known state. This is
important because the RX delay has to be coordinated between the PHY,
MAC and the PCB design (trace length). With an invalid RX delay applied
(for example if both PHY and MAC add a 2ns RX delay) Ethernet may not
work at all.Also add debug logging when configuring the RX delay (just like the TX
delay) because this is a common source of problems.Signed-off-by: Martin Blumenstingl
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
RGMII requires a delay of 2ns between the data and the clock signal.
There are at least three ways this can happen. One possibility is by
having the PHY generate this delay.
This is a common source for problems (for example with slow TX speeds or
packet loss when sending data). The TX delay configuration of the
RTL8211F PHY can be set either by pin-strappping the RXD1 pin (HIGH
means enabled, LOW means disabled) or through configuring a paged
register. The setting from the RXD1 pin is also reflected in the
register.Add debug logging to the TX delay configuration on RTL8211F so it's
easier to spot these issues (for example if the TX delay is enabled for
both, the RTL8211F PHY and the MAC).
This is especially helpful because there is no public datasheet for the
RTL8211F PHY available with all the RX/TX delay specifics.Signed-off-by: Martin Blumenstingl
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
Ido Schimmel says:
====================
mlxsw: spectrum_router: CleanupsThis patch set removes from mlxsw code that is no longer necessary after
the simplification of the IPv4 and IPv6 route offload API.The patches eliminate unnecessary code by taking advantage of the fact
that mlxsw no longer needs to maintain a list of identical routes,
following recent changes in route offload API.
====================Signed-off-by: David S. Miller
-
As explained in previous patches, the driver no longer needs to maintain
a list of identical FIB entries (i.e, same {tb_id, prefix, prefix
length}) and therefore each FIB node can only store one FIB entry.Remove the FIB entry list and simplify the code.
Signed-off-by: Ido Schimmel
Acked-by: Jiri Pirko
Signed-off-by: David S. Miller -
After the last patch mlxsw_sp_fib{4,6}_node_entry_link() and
mlxsw_sp_fib{4,6}_node_entry_unlink() are identical and can therefore be
consolidated into the same common function.Perform the consolidation.
Signed-off-by: Ido Schimmel
Acked-by: Jiri Pirko
Signed-off-by: David S. Miller -
Host routes that perform decapsulation of IP in IP tunnels have a
special adjacency entry linked to them. This entry stores information
such as the expected underlay source IP. When the route is deleted this
entry needs to be freed.The allocation of the adjacency entry happens in
mlxsw_sp_fib4_entry_type_set(), but it is freed in
mlxsw_sp_fib4_node_entry_unlink().Create a new function - mlxsw_sp_fib4_entry_type_unset() - and free the
adjacency entry there.This will allow us to consolidate mlxsw_sp_fib{4,6}_node_entry_unlink()
in the next patch.Signed-off-by: Ido Schimmel
Acked-by: Jiri Pirko
Signed-off-by: David S. Miller -
Since the driver no longer maintains a list of identical routes there is
no route to promote when a route is deleted.Remove that code that took care of it.
Signed-off-by: Ido Schimmel
Acked-by: Jiri Pirko
Signed-off-by: David S. Miller -
Now that the networking stack takes care of only notifying the routes of
interest, we do not need to maintain a list of identical routes.Remove the check that tests if the route is the first route in the FIB
node.Signed-off-by: Ido Schimmel
Acked-by: Jiri Pirko
Signed-off-by: David S. Miller -
As the LACP actor/partner state is now part of the uapi, rename the
3ad state defines with LACP prefix. The LACP prefix is preferred over
BOND_3AD as the LACP standard moved to 802.1AX.Fixes: 826f66b30c2e3 ("bonding: move 802.3ad port state flags to uapi")
Signed-off-by: Andy Roulin
Signed-off-by: David S. Miller -
The original patch bringed in the "SCTP ACK tracking trace event"
feature was committed at Dec.20, 2017, it replaced jprobe usage
with trace events, and bringed in two trace events, one is
TRACE_EVENT(sctp_probe), another one is TRACE_EVENT(sctp_probe_path).
The original patch intended to trigger the trace_sctp_probe_path in
TRACE_EVENT(sctp_probe) as below code,+TRACE_EVENT(sctp_probe,
+
+ TP_PROTO(const struct sctp_endpoint *ep,
+ const struct sctp_association *asoc,
+ struct sctp_chunk *chunk),
+
+ TP_ARGS(ep, asoc, chunk),
+
+ TP_STRUCT__entry(
+ __field(__u64, asoc)
+ __field(__u32, mark)
+ __field(__u16, bind_port)
+ __field(__u16, peer_port)
+ __field(__u32, pathmtu)
+ __field(__u32, rwnd)
+ __field(__u16, unack_data)
+ ),
+
+ TP_fast_assign(
+ struct sk_buff *skb = chunk->skb;
+
+ __entry->asoc = (unsigned long)asoc;
+ __entry->mark = skb->mark;
+ __entry->bind_port = ep->base.bind_addr.port;
+ __entry->peer_port = asoc->peer.port;
+ __entry->pathmtu = asoc->pathmtu;
+ __entry->rwnd = asoc->peer.rwnd;
+ __entry->unack_data = asoc->unack_data;
+
+ if (trace_sctp_probe_path_enabled()) {
+ struct sctp_transport *sp;
+
+ list_for_each_entry(sp, &asoc->peer.transport_addr_list,
+ transports) {
+ trace_sctp_probe_path(sp, asoc);
+ }
+ }
+ ),But I found it did not work when I did testing, and trace_sctp_probe_path
had no output, I finally found that there is trace buffer lock
operation(trace_event_buffer_reserve) in include/trace/trace_events.h:static notrace void \
trace_event_raw_event_##call(void *__data, proto) \
{ \
struct trace_event_file *trace_file = __data; \
struct trace_event_data_offsets_##call __maybe_unused __data_offsets;\
struct trace_event_buffer fbuffer; \
struct trace_event_raw_##call *entry; \
int __data_size; \
\
if (trace_trigger_soft_disabled(trace_file)) \
return; \
\
__data_size = trace_event_get_offsets_##call(&__data_offsets, args); \
\
entry = trace_event_buffer_reserve(&fbuffer, trace_file, \
sizeof(*entry) + __data_size); \
\
if (!entry) \
return; \
\
tstruct \
\
{ assign; } \
\
trace_event_buffer_commit(&fbuffer); \
}The reason caused no output of trace_sctp_probe_path is that
trace_sctp_probe_path written in TP_fast_assign part of
TRACE_EVENT(sctp_probe), and it will be placed( { assign; } ) after the
trace_event_buffer_reserve() when compiler expands Macro,entry = trace_event_buffer_reserve(&fbuffer, trace_file, \
sizeof(*entry) + __data_size); \
\
if (!entry) \
return; \
\
tstruct \
\
{ assign; } \so trace_sctp_probe_path finally can not acquire trace_event_buffer
and return no output, that is to say the nest of tracepoint entry function
is not allowed. The function call flow is:trace_sctp_probe()
-> trace_event_raw_event_sctp_probe()
-> lock buffer
-> trace_sctp_probe_path()
-> trace_event_raw_event_sctp_probe_path() --nested
-> buffer has been locked and return no output.This patch is to remove trace_sctp_probe_path from the TP_fast_assign
part of TRACE_EVENT(sctp_probe) to avoid the nest of entry function,
and trigger sctp_probe_path_trace in sctp_outq_sack.After this patch, you can enable both events individually,
# cd /sys/kernel/debug/tracing
# echo 1 > events/sctp/sctp_probe/enable
# echo 1 > events/sctp/sctp_probe_path/enableOr, you can enable all the events under sctp.
# echo 1 > events/sctp/enable
Signed-off-by: Kevin Kou
Acked-by: Marcelo Ricardo Leitner
Signed-off-by: David S. Miller
26 Dec, 2019
13 commits
-
Richard Cochran says:
====================
Peer to Peer One-Step time stampingThis series adds support for PTP (IEEE 1588) P2P one-step time
stamping along with a driver for a hardware device that supports this.If the hardware supports p2p one-step, it subtracts the ingress time
stamp value from the Pdelay_Request correction field. The user space
software stack then simply copies the correction field into the
Pdelay_Response, and on transmission the hardware adds the egress time
stamp into the correction field.This new functionality extends CONFIG_NETWORK_PHY_TIMESTAMPING to
cover MII snooping devices, but it still depends on phylib, just as
that option does. Expanding beyond phylib is not within the scope of
the this series.User space support is available in the current linuxptp master branch.
- Patch 1 adds phy_device methods for existing time stamping fields.
- Patches 2-5 convert the stack and drivers to the new methods.
- Patch 6 moves code around the dp83640 driver.
- Patches 7-10 add support for MII time stamping in non-PHY devices.
- Patch 11 adds the new P2P 1-step option.
- Patch 12 adds a driver implementing the new option.Thanks,
RichardChanged in v9:
~~~~~~~~~~~~~~- Fix two more drivers' switch/case blocks WRT the new HWTSTAMP ioctl.
- Picked up two more review tags from Andrew.Changed in v8:
~~~~~~~~~~~~~~- Avoided adding forward functional declarations in the dp83640 driver.
- Picked up Florian's new review tags and another one from Andrew.Changed in v7:
~~~~~~~~~~~~~~- Converted pr_debug|err to dev_ variants in new driver.
- Fixed device tree documentation per Rob's v6 review.
- Picked up Andrew's and Rob's review tags.
- Silenced sparse warnings in new driver.Changed in v6:
~~~~~~~~~~~~~~- Added methods for accessing the phy_device time stamping fields.
- Adjust the device tree documentation per Rob's v5 review.
- Fixed the build failures due to missing exports.Changed in v5:
~~~~~~~~~~~~~~- Fixed build failure in macvlan.
- Fixed latent bug with its gcc warning in the driver.Changed in v4:
~~~~~~~~~~~~~~- Correct error paths and PTR_ERR return values in the framework.
- Expanded KernelDoc comments WRT PHY locking.
- Pick up Andrew's review tag.Changed in v3:
~~~~~~~~~~~~~~- Simplify the device tree binding and document the time stamping
phandle by itself.Changed in v2:
~~~~~~~~~~~~~~- Per the v1 review, changed the modeling of MII time stamping
devices. They are no longer a kind of mdio device.
====================Signed-off-by: David S. Miller
-
The InES at the ZHAW offers a PTP time stamping IP core. The FPGA
logic recognizes and time stamps PTP frames on the MII bus. This
patch adds a driver for the core along with a device tree binding to
allow hooking the driver to MII buses.Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
The 1588 standard defines one step operation for both Sync and
PDelay_Resp messages. Up until now, hardware with P2P one step has
been rare, and kernel support was lacking. This patch adds support of
the mode in anticipation of new hardware developments.Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
When parsing a PHY node, register its time stamper, if any, and attach
the instance to the PHY device.Signed-off-by: Richard Cochran
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Reviewed-by: Rob Herring
Signed-off-by: David S. Miller -
This patch add a new binding that allows non-PHY MII time stamping
devices to find their buses. The new documentation covers both the
generic binding and one upcoming user.Signed-off-by: Richard Cochran
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
While PHY time stamping drivers can simply attach their interface
directly to the PHY instance, stand alone drivers require support in
order to manage their services. Non-PHY MII time stamping drivers
have a control interface over another bus like I2C, SPI, UART, or via
a memory mapped peripheral. The controller device will be associated
with one or more time stamping channels, each of which sits snoops in
on a MII bus.This patch provides a glue layer that will enable time stamping
channels to find their controlling device.Signed-off-by: Richard Cochran
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Currently the stack supports time stamping in PHY devices. However,
there are newer, non-PHY devices that can snoop an MII bus and provide
time stamps. In order to support such devices, this patch introduces
a new interface to be used by both PHY and non-PHY devices.In addition, the one and only user of the old PHY time stamping API is
converted to the new interface.Signed-off-by: Richard Cochran
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
An upcoming patch will change how the PHY time stamping functions are
registered with the networking stack, and adapting this driver would
entail adding forward declarations for four time stamping methods.
However, forward declarations are considered to be stylistic defects.
This patch avoids the issue by moving the probe and remove methods
immediately above the phy_driver interface structure.Signed-off-by: Richard Cochran
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
The netcp_ethss driver tests fields of the phy_device in order to
determine whether to defer to the PHY's time stamping functionality.
This patch replaces the open coded logic with an invocation of the
proper methods.Signed-off-by: Richard Cochran
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
The ethtool layer tests fields of the phy_device in order to determine
whether to invoke the PHY's tsinfo ethtool callback. This patch
replaces the open coded logic with an invocation of the proper
methods.Signed-off-by: Richard Cochran
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
The vlan layer tests fields of the phy_device in order to determine
whether to invoke the PHY's tsinfo ethtool callback. This patch
replaces the open coded logic with an invocation of the proper
methods.Signed-off-by: Richard Cochran
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
The macvlan layer tests fields of the phy_device in order to determine
whether to invoke the PHY's tsinfo ethtool callback. This patch
replaces the open coded logic with an invocation of the proper
methods.Signed-off-by: Richard Cochran
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
Some parts of the networking stack and at least one driver test fields
within the 'struct phy_device' in order to query time stamping
capabilities and to invoke time stamping methods. This patch adds a
functional interface around the time stamping fields. This will allow
insulating the callers from future changes to the details of the time
stamping implemenation.Signed-off-by: Richard Cochran
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
25 Dec, 2019
17 commits
-
Ido Schimmel says:
====================
Simplify IPv6 route offload APIMotivation
==========This is the IPv6 counterpart of "Simplify IPv4 route offload API" [1].
The aim of this patch set is to simplify the IPv6 route offload API by
making the stack a bit smarter about the notifications it is generating.
This allows driver authors to focus on programming the underlying device
instead of having to duplicate the IPv6 route insertion logic in their
driver, which is error-prone.Details
=======Today, whenever an IPv6 route is added or deleted a notification is sent
in the FIB notification chain and it is up to offload drivers to decide
if the route should be programmed to the hardware or not. This is not an
easy task as in hardware routes are keyed by {prefix, prefix length,
table id}, whereas the kernel can store multiple such routes that only
differ in metric / nexthop info.This series makes sure that only routes that are actually used in the
data path are notified to offload drivers. This greatly simplifies the
work these drivers need to do, as they are now only concerned with
programming the hardware and do not need to replicate the IPv6 route
insertion logic and store multiple identical routes.The route that is notified is the first route in the IPv6 FIB node,
which represents a single prefix and length in a given table. In case
the route is deleted and there is another route with the same key, a
replace notification is emitted. Otherwise, a delete notification is
emitted.Unlike IPv4, in IPv6 it is possible to append individual nexthops to an
existing multipath route. Therefore, in addition to the replace and
delete notifications present in IPv4, an append notification is also
used.Testing
=======To ensure there is no degradation in route insertion rates, I averaged
the insertion rate of 512k routes (/64 and /128) over 50 runs. Did not
observe any degradation.Functional tests are available here [2]. They rely on route trap
indication, which is added in a subsequent patch set.In addition, I have been running syzkaller for the past couple of weeks
with debug options enabled. Did not observe any problems.Patch set overview
==================Patches #1-#7 gradually introduce the new FIB notifications
Patch #8 converts mlxsw to use the new notifications
Patch #9 remove the old notifications[1] https://patchwork.ozlabs.org/cover/1209738/
[2] https://github.com/idosch/linux/tree/fib-notifier
====================Signed-off-by: David S. Miller
-
Now that mlxsw is converted to use the new FIB notifications it is
possible to delete the old ones and use the new replace / append /
delete notifications.Signed-off-by: Ido Schimmel
Reviewed-by: Jiri Pirko
Reviewed-by: David Ahern
Signed-off-by: David S. Miller -
With the new notifications mlxsw does not need to handle identical
routes itself, as this is taken care of by the core IPv6 code.Instead, mlxsw only needs to take care of inserting and removing routes
from the device.Convert mlxsw to use the new IPv6 route notifications and simplify the
code.Signed-off-by: Ido Schimmel
Reviewed-by: Jiri Pirko
Signed-off-by: David S. Miller -
When an entire multipath route is deleted, only emit a notification if
it is the first route in the node. Emit a replace notification in case
the last sibling is followed by another route. Otherwise, emit a delete
notification.Signed-off-by: Ido Schimmel
Reviewed-by: Jiri Pirko
Reviewed-by: David Ahern
Signed-off-by: David S. Miller -
For the purpose of route offload, when a single route is deleted, it is
only of interest if it is the first route in the node or if it is
sibling to such a route.In the first case, distinguish between several possibilities:
1. Route is the last route in the node. Emit a delete notification
2. Route is followed by a non-multipath route. Emit a replace
notification for the non-multipath route.3. Route is followed by a multipath route. Emit a replace notification
for the multipath route.In the second case, only emit a delete notification to ensure the route
is no longer used as a valid nexthop.Signed-off-by: Ido Schimmel
Reviewed-by: Jiri Pirko
Reviewed-by: David Ahern
Signed-off-by: David S. Miller -
When a new listener is registered to the FIB notification chain it
receives a dump of all the available routes in the system. Instead, make
sure to only replay the IPv6 routes that are actually used in the data
path and are of any interest to the new listener.This is done by iterating over all the routing tables in the given
namespace, but from each traversed node only the first route ('leaf') is
notified. Multipath routes are notified in a single notification instead
of one for each nexthop.Add fib6_rt_dump_tmp() to do that. Later on in the patch set it will be
renamed to fib6_rt_dump() instead of the existing one.Signed-off-by: Ido Schimmel
Reviewed-by: Jiri Pirko
Reviewed-by: David Ahern
Signed-off-by: David S. Miller -
In a similar fashion to previous patches, only notify the new multipath
route if it is the first route in the node or if it was appended to such
route.The type of the notification (replace vs. append) is determined based on
the number of routes added ('nhn') and the number of sibling routes. If
the two do not match, then an append notification should be sent.Signed-off-by: Ido Schimmel
Reviewed-by: Jiri Pirko
Reviewed-by: David Ahern
Signed-off-by: David S. Miller -
Similar to the corresponding IPv4 patch, only notify the new route if it
is replacing the currently offloaded one. Meaning, the one pointed to by
'fn->leaf'.Signed-off-by: Ido Schimmel
Reviewed-by: Jiri Pirko
Reviewed-by: David Ahern
Signed-off-by: David S. Miller -
fib6_add_rt2node() takes care of adding a single route ('struct
fib6_info') to a FIB node. The route in question should only be notified
in case it is added as the first route in the node (lowest metric) or if
it is added as a sibling route to the first route in the node.The first criterion can be tested by checking if the route is pointed to
by 'fn->leaf'. The second criterion can be tested by checking the new
'notify_sibling_rt' variable that is set when the route is added as a
sibling to the first route in the node.Signed-off-by: Ido Schimmel
Reviewed-by: Jiri Pirko
Reviewed-by: David Ahern
Signed-off-by: David S. Miller -
Subsequent patches are going to simplify the IPv6 route offload API,
which will only use three events - replace, delete and append.Introduce a temporary version of replace and delete in order to make the
conversion easier to review. Note that append does not need a temporary
version, as it is currently not used.Signed-off-by: Ido Schimmel
Reviewed-by: Jiri Pirko
Reviewed-by: David Ahern
Signed-off-by: David S. Miller -
Simplify the code by moving the call to rtl_enable_eee() from the
individual PHY configs to rtl8169_init_phy().Signed-off-by: Heiner Kallweit
Signed-off-by: David S. Miller -
Due to recent changes we don't need the call to rtl_rar_exgmac_set()
and longer at this place. It's called from rtl_rar_set() which is
called in rtl_init_mac_address() and rtl8169_resume().Signed-off-by: Heiner Kallweit
Signed-off-by: David S. Miller -
Simplify and factor out this magic from rtl8168h_2_hw_phy_config()
and name it based on the vendor driver.Signed-off-by: Heiner Kallweit
Signed-off-by: David S. Miller -
Martin Varghese says:
====================
New openvswitch MPLS actions for layer 2 tunnellingThe existing PUSH MPLS action inserts MPLS header between ethernet header
and the IP header. Though this behaviour is fine for L3 VPN where an IP
packet is encapsulated inside a MPLS tunnel, it does not suffice the L2
VPN (l2 tunnelling) requirements. In L2 VPN the MPLS header should
encapsulate the ethernet packet.The new mpls action ADD_MPLS inserts MPLS header at the start of the
packet or at the start of the l3 header depending on the value of l3 tunnel
flag in the ADD_MPLS arguments.POP_MPLS action is extended to support ethertype 0x6558
OVS userspace changes -
---------------------
Encap & Decap ovs actions are extended to support MPLS packet type. The encap & decap
adds and removes MPLS header at the start of packet as depicted below.Actions - encap(mpls(ether_type=0x8847)),encap(ethernet)
Incoming packet -> | ETH | IP | Payload |
1 Actions - encap(mpls(ether_type=0x8847)) [Kernel action - add_mpls:0x8847]
Outgoing packet -> | MPLS | ETH | Payload|
2 Actions - encap(ethernet) [ Kernel action - push_eth ]
Outgoing packet -> | ETH | MPLS | ETH | Payload|
Decapsulation:
Incoming packet -> | ETH | MPLS | ETH | IP | Payload |
Actions - decap(),decap(packet_type(ns=0,type=0)
1 Actions - decap() [Kernel action - pop_eth)
Outgoing packet -> | MPLS | ETH | IP | Payload|
2 Actions - decap(packet_type(ns=0,type=0) [Kernel action - pop_mpls:0x6558]
Outgoing packet -> | ETH | IP | Payload
====================Signed-off-by: David S. Miller
-
The existing PUSH MPLS action inserts MPLS header between ethernet header
and the IP header. Though this behaviour is fine for L3 VPN where an IP
packet is encapsulated inside a MPLS tunnel, it does not suffice the L2
VPN (l2 tunnelling) requirements. In L2 VPN the MPLS header should
encapsulate the ethernet packet.The new mpls action ADD_MPLS inserts MPLS header at the start of the
packet or at the start of the l3 header depending on the value of l3 tunnel
flag in the ADD_MPLS arguments.POP_MPLS action is extended to support ethertype 0x6558.
Signed-off-by: Martin Varghese
Acked-by: Pravin B Shelar
Signed-off-by: David S. Miller -
Rephrased comments section of skb_mpls_pop() to align it with
comments section of skb_mpls_push().Signed-off-by: Martin Varghese
Acked-by: Pravin B Shelar
Signed-off-by: David S. Miller -
The existing skb_mpls_push() implementation always inserts mpls header
after the mac header. L2 VPN use cases requires MPLS header to be
inserted before the ethernet header as the ethernet packet gets tunnelled
inside MPLS header in those cases.Signed-off-by: Martin Varghese
Acked-by: Pravin B Shelar
Signed-off-by: David S. Miller
