- 12 Jun, 2023 34 commits
-
-
Jakub Kicinski authored
Ethtool has an attribute set called stringset, from which we'll generate struct ethtool_stringset. Unfortunately, the old ethtool header declares enum ethtool_stringset (the same name), to which compilers object. This seems unavoidable. Check struct names against known constants and append an underscore if conflict is detected. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
If attr set or enum has empty enum name we need to use u32 or int as function arguments and struct members. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Most of the C enum names are guessed correctly, but there is a handful of corner cases we need to name explicitly. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Ethtool's PSE PoDL has a attr nest with different prefixes: /* Power Sourcing Equipment */ enum { ETHTOOL_A_PSE_UNSPEC, ETHTOOL_A_PSE_HEADER, /* nest - _A_HEADER_* */ ETHTOOL_A_PODL_PSE_ADMIN_STATE, /* u32 */ ETHTOOL_A_PODL_PSE_ADMIN_CONTROL, /* u32 */ ETHTOOL_A_PODL_PSE_PW_D_STATUS, /* u32 */ Header has a prefix of ETHTOOL_A_PSE_ and other attrs prefix of ETHTOOL_A_PODL_PSE_ we can't cover them uniformly. If PODL was after PSE life would be easy. Now we either need to add prefixes to attr names which is yucky or support setting prefix name per attr. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
ynl-regen needs to know the arguments used to generate a file. Record excluded ops and, while at it, user headers. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
The ethtool family has a small handful of quite tricky ops and a lot of simple very useful ops. Teach ynl-gen to skip ops so that we can bypass the tricky ones. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Rob Herring authored
Use the recently added of_property_read_reg() helper to get the untranslated "reg" address value. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Krzysztof Kozlowski authored
Cleanup bindings dropping unneeded quotes. Once all these are fixed, checking for this can be enabled in yamllint. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Alexander Mikhalitsyn says: ==================== Add SCM_PIDFD and SO_PEERPIDFD 1. Implement SCM_PIDFD, a new type of CMSG type analogical to SCM_CREDENTIALS, but it contains pidfd instead of plain pid, which allows programmers not to care about PID reuse problem. 2. Add SO_PEERPIDFD which allows to get pidfd of peer socket holder pidfd. This thing is direct analog of SO_PEERCRED which allows to get plain PID. 3. Add SCM_PIDFD / SO_PEERPIDFD kselftest Idea comes from UAPI kernel group: https://uapi-group.org/kernel-features/ Big thanks to Christian Brauner and Lennart Poettering for productive discussions about this and Luca Boccassi for testing and reviewing this. === Motivation behind this patchset Eric Dumazet raised a question: > It seems that we already can use pidfd_open() (since linux-5.3), and > pass the resulting fd in af_unix SCM_RIGHTS message ? Yes, it's possible, but it means that from the receiver side we need to trust the sent pidfd (in SCM_RIGHTS), or always use combination of SCM_RIGHTS+SCM_CREDENTIALS, then we can extract pidfd from SCM_RIGHTS, then acquire plain pid from pidfd and after compare it with the pid from SCM_CREDENTIALS. A few comments from other folks regarding this. Christian Brauner wrote: >Let me try and provide some of the missing background. >There are a range of use-cases where we would like to authenticate a >client through sockets without being susceptible to PID recycling >attacks. Currently, we can't do this as the race isn't fully fixable. >We can only apply mitigations. >What this patchset will allows us to do is to get a pidfd without the >client having to send us an fd explicitly via SCM_RIGHTS. As that's >already possibly as you correctly point out. >But for protocols like polkit this is quite important. Every message is >standalone and we would need to force a complete protocol change where >we would need to require that every client allocate and send a pidfd via >SCM_RIGHTS. That would also mean patching through all polkit users. >For something like systemd-journald where we provide logging facilities >and want to add metadata to the log we would also immensely benefit from >being able to get a receiver-side controlled pidfd. >With the message type we envisioned we don't need to change the sender >at all and can be safe against pid recycling. >Link: https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/154 >Link: https://uapi-group.org/kernel-features Lennart Poettering wrote: >So yes, this is of course possible, but it would mean the pidfd would >have to be transported as part of the user protocol, explicitly sent >by the sender. (Moreover, the receiver after receiving the pidfd would >then still have to somehow be able to prove that the pidfd it just >received actually refers to the peer's process and not some random >process. – this part is actually solvable in userspace, but ugly) >The big thing is simply that we want that the pidfd is associated >*implicity* with each AF_UNIX connection, not explicitly. A lot of >userspace already relies on this, both in the authentication area >(polkit) as well as in the logging area (systemd-journald). Right now >using the PID field from SO_PEERCREDS/SCM_CREDENTIALS is racy though >and very hard to get right. Making this available as pidfd too, would >solve this raciness, without otherwise changing semantics of it all: >receivers can still enable the creds stuff as they wish, and the data >is then implicitly appended to the connections/datagrams the sender >initiates. >Or to turn this around: things like polkit are typically used to >authenticate arbitrary dbus methods calls: some service implements a >dbus method call, and when an unprivileged client then issues that >call, it will take the client's info, go to polkit and ask it if this >is ok. If we wanted to send the pidfd as part of the protocol we >basically would have to extend every single method call to contain the >client's pidfd along with it as an additional argument, which would be >a massive undertaking: it would change the prototypes of basically >*all* methods a service defines… And that's just ugly. >Note that Alex' patch set doesn't expose anything that wasn't exposed >before, or attach, propagate what wasn't before. All it does, is make >the field already available anyway (the struct ucred .pid field) >available also in a better way (as a pidfd), to solve a variety of >races, with no effect on the protocol actually spoken within the >AF_UNIX transport. It's a seamless improvement of the status quo. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Mikhalitsyn authored
Let's make CONFIG_UNIX a bool instead of a tristate. We've decided to do that during discussion about SCM_PIDFD patchset [1]. [1] https://lore.kernel.org/lkml/20230524081933.44dc8bea@kernel.org/ Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Leon Romanovsky <leon@kernel.org> Cc: David Ahern <dsahern@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Kees Cook <keescook@chromium.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Kuniyuki Iwashima <kuniyu@amazon.com> Cc: Lennart Poettering <mzxreary@0pointer.de> Cc: Luca Boccassi <bluca@debian.org> Cc: linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-arch@vger.kernel.org Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> Acked-by: Christian Brauner <brauner@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Mikhalitsyn authored
Basic test to check consistency between: - SCM_CREDENTIALS and SCM_PIDFD - SO_PEERCRED and SO_PEERPIDFD Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Leon Romanovsky <leon@kernel.org> Cc: David Ahern <dsahern@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Kees Cook <keescook@chromium.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Kuniyuki Iwashima <kuniyu@amazon.com> Cc: linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-kselftest@vger.kernel.org Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Mikhalitsyn authored
Add SO_PEERPIDFD which allows to get pidfd of peer socket holder pidfd. This thing is direct analog of SO_PEERCRED which allows to get plain PID. Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Leon Romanovsky <leon@kernel.org> Cc: David Ahern <dsahern@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Kees Cook <keescook@chromium.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Kuniyuki Iwashima <kuniyu@amazon.com> Cc: Lennart Poettering <mzxreary@0pointer.de> Cc: Luca Boccassi <bluca@debian.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Stanislav Fomichev <sdf@google.com> Cc: bpf@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-arch@vger.kernel.org Reviewed-by: Christian Brauner <brauner@kernel.org> Acked-by: Stanislav Fomichev <sdf@google.com> Tested-by: Luca Boccassi <bluca@debian.org> Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Mikhalitsyn authored
Implement SCM_PIDFD, a new type of CMSG type analogical to SCM_CREDENTIALS, but it contains pidfd instead of plain pid, which allows programmers not to care about PID reuse problem. We mask SO_PASSPIDFD feature if CONFIG_UNIX is not builtin because it depends on a pidfd_prepare() API which is not exported to the kernel modules. Idea comes from UAPI kernel group: https://uapi-group.org/kernel-features/ Big thanks to Christian Brauner and Lennart Poettering for productive discussions about this. Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Leon Romanovsky <leon@kernel.org> Cc: David Ahern <dsahern@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Kees Cook <keescook@chromium.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Kuniyuki Iwashima <kuniyu@amazon.com> Cc: Lennart Poettering <mzxreary@0pointer.de> Cc: Luca Boccassi <bluca@debian.org> Cc: linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-arch@vger.kernel.org Tested-by: Luca Boccassi <bluca@debian.org> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Petr Machata says: ==================== mlxsw: Cleanups in router code This patchset moves some router-related code from spectrum.c to spectrum_router.c where it should be. It also simplifies handlers of netevent notifications. - Patch #1 caches router pointer in a dedicated variable. This obviates the need to access the same as mlxsw_sp->router, making lines shorter, and permitting a future patch to add code that fits within 80 character limit. - Patch #2 moves IP / IPv6 validation notifier blocks from spectrum.c to spectrum_router, where the handlers are anyway. - In patch #3, pass router pointer to scheduler of deferred work directly, instead of having it deduce it on its own. - This makes the router pointer available in the handler function mlxsw_sp_router_netevent_event(), so in patch #4, use it directly, instead of finding it through mlxsw_sp_port. - In patch #5, extend mlxsw_sp_router_schedule_work() so that the NETEVENT_NEIGH_UPDATE handler can use it directly instead of inlining equivalent code. - In patches #6 and #7, add helpers for two common operations involving a backing netdev of a RIF. This makes it unnecessary for the function mlxsw_sp_rif_dev() to be visible outside of the router module, so in patch #8, hide it. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Now that the external users of mlxsw_sp_rif_dev() have been converted in the preceding patches, make the function static. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
In a number of places, a netdevice underlying a RIF is obtained only to compare it to another pointer. In order to clean up the interface between the router and the other modules, add a new helper to specifically answer this question, and convert the relevant uses to this new interface. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
In a number of places, a netdevice underlying a RIF is obtained only to check if it a NULL pointer. In order to clean up the interface between the router and the other modules, add a new helper to specifically answer this question, and convert the relevant uses to this new interface. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
After the struct mlxsw_sp_netevent_work.n field initialization is moved here, the body of code that handles NETEVENT_NEIGH_UPDATE is almost identical to the one in the helper function. Therefore defer to the helper instead of inlining the equivalent. Note that previously, the code took and put a reference of the netdevice. The new code defers to mlxsw_sp_dev_lower_is_port() to obviate the need for taking the reference. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
This code handles NETEVENT_DELAY_PROBE_TIME_UPDATE, which is invoked every time the delay_probe_time changes. mlxsw router currently only maintains one timer, so the last delay_probe_time set wins. Currently, mlxsw uses mlxsw_sp_port_lower_dev_hold() to find a reference to the router. This is no longer necessary. But as a side effect, this makes sure that only updates to "interesting netdevices" (ones that have a physical netdevice lower) are projected. Retain that side effect by calling mlxsw_sp_port_dev_lower_find_rcu() and punting if there is none. Then just proceed using the router pointer that's already at hand in the helper. Note that previously, the code took and put a reference of the netdevice. Because the mlxsw_sp pointer is now obtained from the notifier block, the port pointer (non-) NULL-ness is all that's relevant, and the reference does not need to be taken anymore. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Instead of passing a notifier block and deducing the router pointer from that in the helper, do that in the caller, and pass the result. In the following patches, the pointer will also be made useful in the caller. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
The validation logic is already in the router code. Move there the notifier blocks themselves as well. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Make mlxsw_sp_router_fini() more similar to the _init() function (and more concise) by extracting the `router' handle to a named variable and using that throughout. The availability of a dedicated `router' variable will come in handy in following patches. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Aaron Conole authored
Since its introduction, the ovs module execute_hash action allowed hash algorithms other than the skb->l4_hash to be used. However, additional hash algorithms were not implemented. This means flows requiring different hash distributions weren't able to use the kernel datapath. Now, introduce support for symmetric hashing algorithm as an alternative hash supported by the ovs module using the flow dissector. Output of flow using l4_sym hash: recirc_id(0),in_port(3),eth(),eth_type(0x0800), ipv4(dst=64.0.0.0/192.0.0.0,proto=6,frag=no), packets:30473425, bytes:45902883702, used:0.000s, flags:SP., actions:hash(sym_l4(0)),recirc(0xd) Some performance testing with no GRO/GSO, two veths, single flow: hash(l4(0)): 4.35 GBits/s hash(l4_sym(0)): 4.24 GBits/s Signed-off-by: Aaron Conole <aconole@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Vladimir Oltean says: ==================== Fixes for taprio xstats 1. Taprio classes correspond to TXQs, and thus, class stats are TXQ stats not TC stats. 2. Drivers reporting taprio xstats should report xstats for *this* taprio, not for a previous one. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
Currently, the window_drop stats persist even if an incorrect Qdisc was removed from the interface and a new one is installed. This is because the enetc driver keeps the state, and that is persistent across multiple Qdiscs. To resolve the issue, clear all win_drop counters from all TX queues when the currently active Qdisc is removed. These counters are zero by default. The counters visible in ethtool -S are also affected, but I don't care very much about preserving those enough to keep them monotonically incrementing. Fixes: 4802fca8 ("net: enetc: report statistics counters for taprio") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
The taprio Qdisc creates child classes per netdev TX queue, but taprio_dump_class_stats() currently reports offload statistics per traffic class. Traffic classes are groups of TXQs sharing the same dequeue priority, so this is incorrect and we shouldn't be bundling up the TXQ stats when reporting them, as we currently do in enetc. Modify the API from taprio to drivers such that they report TXQ offload stats and not TC offload stats. There is no change in the UAPI or in the global Qdisc stats. Fixes: 6c1adb65 ("net/sched: taprio: add netlink reporting for offload statistics counters") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Simon Horman authored
Use a __be16 variable to store the big endian value of header in nxp_nci_i2c_fw_read(). Flagged by Sparse as: .../i2c.c:113:22: warning: cast to restricted __be16 No functional changes intended. Compile tested only. Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Haiyang Zhang authored
To support vlan, use MANA_LONG_PKT_FMT if vlan tag is present in TX skb. Then extract the vlan tag from the skb struct, and save it to tx_oob for the NIC to transmit. For vlan tags on the payload, they are accepted by the NIC too. For RX, extract the vlan tag from CQE and put it into skb. Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Martin Habets authored
Reuse the work done for EF100 to add devlink support for EF10. There is no devlink port support for EF10. Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiapeng Chong authored
./net/sched/act_pedit.c:245:21-28: WARNING opportunity for kmemdup. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5478Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by: Pedro Tammela <pctammela@mojatatu.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nitya Sunkad authored
Following the example of 'commit 9a0f830f ("ethtool: linkstate: add a statistic for PHY down events")', added support for link down events. Add callback ionic_get_link_ext_stats to ionic_ethtool.c to support link_down_count, a property of netdev that gets reported exclusively on physical link down events. Run ethtool -I <devname> to display the device link down count. Signed-off-by: Nitya Sunkad <nitya.sunkad@amd.com> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== ice: Improve miscellaneous interrupt code Jacob Keller says: This series improves the driver's use of the threaded IRQ and the communication between ice_misc_intr() and the ice_misc_intr_thread_fn() which was previously introduced by commit 1229b339 ("ice: Add low latency Tx timestamp read"). First, a new custom enumerated return value is used instead of a boolean for ice_ptp_process_ts(). This significantly reduces the cognitive burden when reviewing the logic for this function, as the expected action is clear from the return value name. Second, the unconditional loop in ice_misc_intr_thread_fn() is removed, replacing it with a write to the Other Interrupt Cause register. This causes the MAC to trigger the Tx timestamp interrupt again. This makes it possible to safely use the ice_misc_intr_thread_fn() to handle other tasks beyond just the Tx timestamps. It is also easier to reason about since the thread function will exit cleanly if we do something like disable the interrupt and call synchronize_irq(). Third, refactor the handling for external timestamp events to use the miscellaneous thread function. This resolves an issue with the external time stamps getting blocked while processing the periodic work function task. Fourth, a simplification of the ice_misc_intr() function to always return IRQ_WAKE_THREAD, and schedule the ice service task in the ice_misc_intr_thread_fn() instead. Finally, the Other Interrupt Cause is kept disabled over the thread function processing, rather than immediately re-enabled. Special thanks to Michal Schmidt for the careful review of the series and pointing out my misunderstandings of the kernel IRQ code. It has been determined that the race outlined as being fixed in previous series was actually introduced by this series itself, which I've since corrected. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
M Chetan Kumar authored
Adds runtime pm support for 7560. As part of probe procedure auto suspend is enabled and auto suspend delay is set to 5000 ms for runtime pm use. Later auto flag is set to power manage the device at run time. On successful communication establishment between host and device the device usage counter is dropped and request to put the device into sleep state (suspend). In TX path, the device usage counter is raised and device is moved out of sleep(resume) for data transmission. In RX path, if the device has some data to be sent it request host platform to change the power state by giving PCI PME message. Signed-off-by: M Chetan Kumar <m.chetan.kumar@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Radhey Shyam Pandey authored
Convert the bindings document for Xilinx AXI Ethernet Subsystem from txt to yaml. No changes to existing binding description. Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by: Sarath Babu Naidu Gaddam <sarath.babu.naidu.gaddam@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 11 Jun, 2023 1 commit
-
-
Vladimir Nikishkin authored
The iproute2 output that eventually landed upstream is different than the one used in this test, resulting in failures. Fix by adjusting the test to use iproute2's JSON output, which is more stable than regular output. Fixes: 305c0418 ("selftests: net: vxlan: Add tests for vxlan nolocalbypass option.") Signed-off-by: Vladimir Nikishkin <vladimir@nikishkin.pw> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Tested-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 10 Jun, 2023 5 commits
-
-
David S. Miller authored
Yoshihiro Shimoda says: ==================== net: renesas: rswitch: Improve perfromance of TX/RX This patch series is based on net-next.git / main branch [1]. This patch series can improve perfromance of TX in a specific condition. The previous code used "global rate limiter" feature so that this is possible to cause performance down if we use multiple ports at the same time. To resolve this issue, use "hardware pause" features of GWCA and COMA. Note that this is not related to the ethernet PAUSE frames. < UDP TX by iperf3 > before: about 450Mbps on both tsn0 and tsn1 after: about 950Mbps on both tsn0 and tsn1 Also, this patch series can improve performance of RX by using napi_gro_receive(). < TCP RX by iperf > before: about 670Mbps on tsn0 after: about 840Mbps on tsn0 [1] The commit e06bd5e3 ("Merge branch 'followup-fixes-for-the-dwmac-and-altera-lynx-conversion'") Changes from v3: https://lore.kernel.org/all/20230607015641.1724057-1-yoshihiro.shimoda.uh@renesas.com/ - Rebased on the latest net-next.git / main branch. - Added Reviewed-by in the patch 2/2. (Maciej, thanks!) - Fix typos in the commit description in the patch 2/2. Changes from v2: https://lore.kernel.org/all/20230606085558.1708766-1-yoshihiro.shimoda.uh@renesas.com/ - Rebased on the latest net-next.git / main branch. - Added Reviewed-by in the patch 1/2. (Maciej, thanks!) - Revise the commit description in the patch 2/2. - Add definition to remove magic hardcoded numbers in the patch 2/2. Changes from v1: https://lore.kernel.org/all/20230529080840.1156458-1-yoshihiro.shimoda.uh@renesas.com/ - Rebased on the latest net-next.git / main branch. - Use "hardware pause" feature instead of "per-queue limiter" feature. - Drop refactaring for "per-queue limiter". - Drop dt-bindings update because "hardware pause" doesn't need additional clock information. - Use napi_gro_receive() to improve RX performance. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yoshihiro Shimoda authored
Since this driver used the "global rate limiter" feature of GWCA, the TX performance of each port was reduced when multiple ports transmitted frames simultaneously. To improve performance, remove the use of the "global rate limiter" feature and use "hardware pause" features of the following: - "per priority pause" of GWCA - "global pause" of COMA Note that these features are not related to the ethernet PAUSE frame. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yoshihiro Shimoda authored
This hardware can receive multiple frames so that using napi_gro_receive() instead of netif_receive_skb() gets good performance of RX. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Edward Cree says: ==================== sfc: TC encap actions offload This series adds support for offloading TC tunnel_key set actions to the EF100 driver, supporting VxLAN and GENEVE tunnels over IPv4 or IPv6. ==================== Link: https://lore.kernel.org/r/cover.1686240142.git.ecree.xilinx@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Edward Cree authored
Support constructing VxLAN and GENEVE headers, on either IPv4 or IPv6, using the neighbouring information obtained in encap->neigh to populate the Ethernet header. Note that the ef100 hardware does not insert UDP checksums when performing encap, so for IPv6 the remote endpoint will need to be configured with udp6zerocsumrx or equivalent. Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-