The PPE scheduler settings determine the priority of scheduling the
packet across the different hardware queues per PPE port.
Signed-off-by: Luo Jie
---
drivers/net/ethernet/qualcomm/ppe/ppe_config.c | 789 -
drivers/net/ethernet/qualcomm/ppe/ppe_config.h | 37 ++
driver
The PPE (packet process engine) hardware block is available in Qualcomm
IPQ chipsets that support PPE architecture, such as IPQ9574. The PPE in
the IPQ9574 SoC includes six ethernet ports (6 GMAC and 6 XGMAC), which
are used to connect with external PHY devices by PCS. It includes an L2
switch func
Add maintainer entry for PPE (Packet Process Engine) driver
supported for Qualcomm IPQ SoCs.
Signed-off-by: Luo Jie
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1e930c7a58b1..ad7d56775f63 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@
1. Enable port specific counters in PPE.
2. Configure the default action as drop when the packet size
is more than the configured MTU of physical port.
Signed-off-by: Luo Jie
---
drivers/net/ethernet/qualcomm/ppe/ppe_config.c | 93 +-
drivers/net/ethernet/qualcomm/ppe/
From: Lei Wei
Configure the default L2 bridge settings for the PPE ports to
enable L2 frame forwarding between CPU port and PPE Ethernet
ports.
The per-port L2 bridge settings are initialized as follows:
For PPE CPU port, the PPE bridge TX is enabled and FDB learn is
disabled. For PPE physical p
PPE RSS hash is generated during PPE receive, based on the packet
content (3 tuples or 5 tuples) and as per the configured RSS seed.
The hash is then used to select the queue to transmit the packet
to the ARM CPU.
This patch initializes the RSS hash settings that are used to
generate the hash for
Le 08/01/2025 à 14:47, Luo Jie a écrit :
Configure unicast and multicast hardware queues for the PPE
ports to enable packet forwarding between the ports.
Each PPE port is assigned with a range of queues. The queue ID
selection for a packet is decided by the queue base and queue
offset that is co
Le 08/01/2025 à 14:47, Luo Jie a écrit :
The PPE scheduler settings determine the priority of scheduling the
packet across the different hardware queues per PPE port.
Signed-off-by: Luo Jie
...
+/* Scheduler configuration for dispatching packet on PPE queues, which
+ * is different per SoC.
On Tue, Jan 07, 2025 at 02:42:16PM +1100, Alistair Popple wrote:
> Main updates since v4:
>
> - Removed most of the devdax/fsdax checks in fs/proc/task_mmu.c. This
>means smaps/pagemap may contain DAX pages.
>
> - Fixed rmap accounting of PUD mapped pages.
>
> - Minor code clean-ups.
>
>
On Wed, Jan 08, 2025 at 02:30:24PM -0800, Dan Williams wrote:
> Alistair Popple wrote:
> > FS DAX requires file systems to call into the DAX layout prior to
> > unlinking inodes to ensure there is no ongoing DMA or other remote
> > access to the direct mapped page. The fuse file system implements
>
On Wed, Jan 08, 2025 at 02:50:36PM -0800, Dan Williams wrote:
> Alistair Popple wrote:
> > Several functions internal to FS DAX use the following pattern when
> > trying to obtain an unlocked entry:
> >
> > xas_for_each(&xas, entry, end_idx) {
> > if (dax_is_locked(entry))
> > entr
On Wednesday, January 8, 2025 12:58 AM, Stanislav Fomichev
wrote:
>On 01/06, Song Yoong Siang wrote:
>> Add Launch Time hw offload request to xdp_hw_metadata. User can configure
>> the delta of launch time to HW RX-time by using "-l" argument. The default
>> delta is 100,000,000 nanosecond.
>>
>>
This series depends on: "[PATCH v2 0/3] tun: Unify vnet implementation
and fill full vnet header"
https://lore.kernel.org/r/20250109-tun-v2-0-388d7d5a2...@daynix.com
virtio-net have two usage of hashes: one is RSS and another is hash
reporting. Conventionally the hash calculation was done by the V
They are useful to implement VIRTIO_NET_F_RSS and
VIRTIO_NET_F_HASH_REPORT.
Signed-off-by: Akihiko Odaki
---
include/linux/virtio_net.h | 188 +
1 file changed, 188 insertions(+)
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
ind
flow_keys_dissector_symmetric is useful to derive a symmetric hash
and to know its source such as IPv4, IPv6, TCP, and UDP.
Signed-off-by: Akihiko Odaki
---
include/net/flow_dissector.h | 1 +
net/core/flow_dissector.c| 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/inc
Hash reporting
--
Allow the guest to reuse the hash value to make receive steering
consistent between the host and guest, and to save hash computation.
RSS
---
RSS is a receive steering algorithm that can be negotiated to use with
virtio_net. Conventionally the hash calculation was d
Ensure that vnet ioctls result in EBADFD when the underlying device is
deleted.
Signed-off-by: Akihiko Odaki
---
tools/testing/selftests/net/tun.c | 74 +++
1 file changed, 74 insertions(+)
diff --git a/tools/testing/selftests/net/tun.c
b/tools/testing/selft
On Wednesday, January 8, 2025 1:08 AM, Stanislav Fomichev
wrote:
>On 01/06, Song Yoong Siang wrote:
>> Enable launch time (Time-Based Scheduling) support to XDP zero copy via XDP
>> Tx metadata framework.
>>
>> This patch is tested with tools/testing/selftests/bpf/xdp_hw_metadata on
>> Intel Tige
VIRTIO_NET_F_HASH_REPORT allows to report hash values calculated on the
host. When VHOST_NET_F_VIRTIO_NET_HDR is employed, it will report no
hash values (i.e., the hash_report member is always set to
VIRTIO_NET_HASH_REPORT_NONE). Otherwise, the values reported by the
underlying socket will be repor
On Wednesday, January 8, 2025 12:50 AM, Stanislav Fomichev
wrote:
>On 01/06, Song Yoong Siang wrote:
>> Extend the XDP Tx metadata framework so that user can requests launch time
>> hardware offload, where the Ethernet device will schedule the packet for
>> transmission at a pre-determined time c
The added tests confirm tun can perform RSS and hash reporting, and
reject invalid configurations for them.
Signed-off-by: Akihiko Odaki
---
tools/testing/selftests/net/Makefile | 2 +-
tools/testing/selftests/net/tun.c| 558 ++-
2 files changed, 551 inserti
On Thu, Jan 09, 2025 at 03:58:44PM +0900, Akihiko Odaki wrote:
> tun used to simply advance iov_iter when it needs to pad virtio header,
> which leaves the garbage in the buffer as is. This is especially
> problematic when tun starts to allow enabling the hash reporting
> feature; even if the featu
On Thu, Jan 09, 2025 at 03:58:45PM +0900, Akihiko Odaki wrote:
> The specification says the device MUST set num_buffers to 1 if
> VIRTIO_NET_F_MRG_RXBUF has not been negotiated.
>
> Signed-off-by: Akihiko Odaki
How do we know this is v1 and not v0? Confused.
> ---
> drivers/net/tap.c |
On Wed, Jan 08, 2025 at 04:14:20PM -0800, Dan Williams wrote:
> Alistair Popple wrote:
> > Prior to freeing a block file systems supporting FS DAX must check
> > that the associated pages are both unmapped from user-space and not
> > undergoing DMA or other access from eg. get_user_pages(). This is
On Thu, Jan 09, 2025 at 02:32:25AM -0500, Michael S. Tsirkin wrote:
> On Thu, Jan 09, 2025 at 03:58:45PM +0900, Akihiko Odaki wrote:
> > The specification says the device MUST set num_buffers to 1 if
> > VIRTIO_NET_F_MRG_RXBUF has not been negotiated.
> >
> > Signed-off-by: Akihiko Odaki
>
>
>
On 2025/01/09 16:31, Michael S. Tsirkin wrote:
On Thu, Jan 09, 2025 at 03:58:44PM +0900, Akihiko Odaki wrote:
tun used to simply advance iov_iter when it needs to pad virtio header,
which leaves the garbage in the buffer as is. This is especially
problematic when tun starts to allow enabling the
On Thu, Jan 09, 2025 at 04:41:50PM +0900, Akihiko Odaki wrote:
> On 2025/01/09 16:31, Michael S. Tsirkin wrote:
> > On Thu, Jan 09, 2025 at 03:58:44PM +0900, Akihiko Odaki wrote:
> > > tun used to simply advance iov_iter when it needs to pad virtio header,
> > > which leaves the garbage in the buff
On Thu, Jan 09, 2025 at 02:31:37AM -0500, Michael S. Tsirkin wrote:
> On Thu, Jan 09, 2025 at 03:58:44PM +0900, Akihiko Odaki wrote:
> > tun used to simply advance iov_iter when it needs to pad virtio header,
> > which leaves the garbage in the buffer as is. This is especially
> > problematic when
Both tun and tap exposes the same set of virtio-net-related features.
Unify their implementations to ease future changes.
Signed-off-by: Akihiko Odaki
---
MAINTAINERS| 1 +
drivers/net/Kconfig| 5 ++
drivers/net/Makefile | 1 +
drivers/net/tap.c | 172 ++-
https://lore.kernel.org/r/20241008-rss-v5-0-f3cf68df0...@daynix.com
[2]: https://lore.kernel.org/r/20241227084256-mutt-send-email-...@kernel.org/
Signed-off-by: Akihiko Odaki
---
Changes in v2:
- Fixed num_buffers endian.
- Link to v1:
https://lore.kernel.org/r/20250108-tun-v1-0-67d784b34...@dayni
tun used to simply advance iov_iter when it needs to pad virtio header,
which leaves the garbage in the buffer as is. This is especially
problematic when tun starts to allow enabling the hash reporting
feature; even if the feature is enabled, the packet may lack a hash
value and may contain a hole
The specification says the device MUST set num_buffers to 1 if
VIRTIO_NET_F_MRG_RXBUF has not been negotiated.
Signed-off-by: Akihiko Odaki
---
drivers/net/tap.c | 2 +-
drivers/net/tun.c | 6 --
drivers/net/tun_vnet.c | 14 +-
drivers/net/tun_vnet.h | 4 ++--
4 file
On Wed, Jan 08, 2025 at 09:47:19PM +0800, Luo Jie wrote:
> From: Lei Wei
>
> Configure the default L2 bridge settings for the PPE ports to
> enable L2 frame forwarding between CPU port and PPE Ethernet
> ports.
It would be good to have an 'only' in there:
> to _only_
> enable L2 frame forwardin
On Tue, Jan 07, 2025 at 10:59:41PM +, Mark Brown wrote:
> From: Marc Zyngier
>
> The hwcaps code that exposes SVE features to userspace only
> considers ID_AA64ZFR0_EL1, while this is only valid when
> ID_AA64PFR0_EL1.SVE advertises that SVE is actually supported.
>
> The expectations are th
The PPE hardware packet counters are made available through
the debugfs entry "/sys/kernel/debug/ppe/packet_counters".
Signed-off-by: Luo Jie
---
drivers/net/ethernet/qualcomm/ppe/Makefile | 2 +-
drivers/net/ethernet/qualcomm/ppe/ppe.c | 11 +
drivers/net/ethernet/qualcomm/ppe/p
Configure unicast and multicast hardware queues for the PPE
ports to enable packet forwarding between the ports.
Each PPE port is assigned with a range of queues. The queue ID
selection for a packet is decided by the queue base and queue
offset that is configured based on the internal priority and
PPE service code is a special code (0-255) that is defined by PPE for
PPE's packet processing stages, as per the network functions required
for the packet.
For packet being sent out by ARM cores on Ethernet ports, The service
code 1 is used as the default service code. This service code is used
to
Configure the selected queues to map with an Ethernet DMA ring for the
packet to receive on ARM cores.
As default initialization, all queues assigned to CPU port 0 are mapped
to the EDMA ring 0. This configuration is later updated during Ethernet
DMA initialization.
Signed-off-by: Luo Jie
---
d
QM (queue management) configurations decide the length of PPE
queues and the queue depth for these queues which are used to
drop packets in events of congestion.
There are two types of PPE queues - unicast queues (0-255) and
multicast queues (256-299). These queue types are used to forward
differe
The PPE (Packet Process Engine) hardware block is available
on Qualcomm IPQ SoC that support PPE architecture, such as
IPQ9574.
The PPE in IPQ9574 includes six integrated ethernet MAC
(for 6 PPE ports), buffer management, queue management and
scheduler functions. The MACs can connect with the exte
The BM (Buffer Management) config controls the pause frame generated
on the PPE port. There are maximum 15 BM ports and 4 groups supported,
all BM ports are assigned to group 0 by default. The number of hardware
buffers configured for the port influence the threshold of the flow
control for that po
From: Lei Wei
Add description and high-level diagram for PPE, driver overview and
module enable/debug information.
Signed-off-by: Lei Wei
Signed-off-by: Luo Jie
---
.../networking/device_drivers/ethernet/index.rst | 1 +
.../device_drivers/ethernet/qualcomm/ppe/ppe.rst | 197 +++
/qualcomm/ppe/ppe_debugfs.h| 16 +
drivers/net/ethernet/qualcomm/ppe/ppe_regs.h | 559 ++
14 files changed, 4544 insertions(+)
---
base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37
change-id: 20250108-qcom_ipq_ppe-aa4c4fa0ab73
Best regards,
--
Luo Jie
On Wed, Jan 08, 2025 at 09:47:20PM +0800, Luo Jie wrote:
> The PPE hardware packet counters are made available through
> the debugfs entry "/sys/kernel/debug/ppe/packet_counters".
Why?
Would it not be better to make them available via ethtool -S ?
You should justify not using standard statistics
On Tue, 07 Jan 2025 22:59:40 +, Mark Brown wrote:
> The 2024 architecture release includes a number of data processing
> extensions, mostly SVE and SME additions with a few others. These are
> all very straightforward extensions which add instructions but no
> architectural state so only need
Le 08/01/2025 à 14:47, Luo Jie a écrit :
The PPE (Packet Process Engine) hardware block is available
on Qualcomm IPQ SoC that support PPE architecture, such as
IPQ9574.
The PPE in IPQ9574 includes six integrated ethernet MAC
(for 6 PPE ports), buffer management, queue management and
scheduler fu
Alistair Popple wrote:
> Prior to freeing a block file systems supporting FS DAX must check
> that the associated pages are both unmapped from user-space and not
> undergoing DMA or other access from eg. get_user_pages(). This is
> achieved by unmapping the file range and scanning the FS DAX
> page
Andrew Morton wrote:
> On Tue, 7 Jan 2025 14:42:16 +1100 Alistair Popple wrote:
>
> > Device and FS DAX pages have always maintained their own page
> > reference counts without following the normal rules for page reference
> > counting. In particular pages are considered free when the refcount
>
On Wed, Jan 08, 2025 at 04:50:15AM +, Michael Kelley wrote:
> From: Bagas Sanjaya Sent: Tuesday, January 7, 2025
> 8:07 PM
> >
> > On Tue, Jan 07, 2025 at 12:20:47PM -0800, mhkelle...@gmail.com wrote:
> > > +VMBus devices are identified by class and instance GUID. (See section
> > > +"VMBus
Both tun and tap exposes the same set of virtio-net-related features.
Unify their implementations to ease future changes.
Signed-off-by: Akihiko Odaki
---
MAINTAINERS| 1 +
drivers/net/Kconfig| 5 ++
drivers/net/Makefile | 1 +
drivers/net/tap.c | 172 ++-
When I implemented virtio's hash-related features to tun/tap [1],
I found tun/tap does not fill the entire region reserved for the virtio
header, leaving some uninitialized hole in the middle of the buffer
after read()/recvmesg().
This series fills the uninitialized hole. More concretely, the
num_
tun used to simply advance iov_iter when it needs to pad virtio header,
which leaves the garbage in the buffer as is. This is especially
problematic when tun starts to allow enabling the hash reporting
feature; even if the feature is enabled, the packet may lack a hash
value and may contain a hole
The specification says the device MUST set num_buffers to 1 if
VIRTIO_NET_F_MRG_RXBUF has not been negotiated.
Signed-off-by: Akihiko Odaki
---
drivers/net/tap.c | 2 +-
drivers/net/tun.c | 4 ++--
drivers/net/tun_vnet.c | 14 +-
drivers/net/tun_vnet.h | 4 ++--
4 files
Alistair Popple wrote:
> Several functions internal to FS DAX use the following pattern when
> trying to obtain an unlocked entry:
>
> xas_for_each(&xas, entry, end_idx) {
> if (dax_is_locked(entry))
> entry = get_unlocked_entry(&xas, 0);
>
> This is problematic because get_un
Alistair Popple wrote:
> dax_layout_busy_page_range() is used by file systems to scan the DAX
> page-cache to unmap mapping pages from user-space and to determine if
> any pages in the given range are busy, either due to ongoing DMA or
> other get_user_pages() usage.
>
> Currently it checks to see
Alistair Popple wrote:
> FS DAX requires file systems to call into the DAX layout prior to
> unlinking inodes to ensure there is no ongoing DMA or other remote
> access to the direct mapped page. The fuse file system implements
> fuse_dax_break_layouts() to do this which includes a comment
> indica
56 matches
Mail list logo
