On 2025/01/16 21:54, Willem de Bruijn wrote:
Michael S. Tsirkin wrote:
On Thu, Jan 16, 2025 at 05:08:03PM +0900, Akihiko Odaki wrote:
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 un
On Mon, Jan 13, 2025 at 06:42:46PM -0800, Dan Williams wrote:
> Alistair Popple wrote:
> > At present mlock skips ptes mapping ZONE_DEVICE pages. A future change
> > to remove pmd_devmap will allow pmd_trans_huge_lock() to return
> > ZONE_DEVICE folios so make sure we continue to skip those.
> >
>
On Wed, 15 Jan 2025 05:35:20 -0800 Breno Leitao wrote:
> + WARN_ON_ONCE(userdata_len + sysdata_len >
> + MAX_EXTRADATA_ENTRY_LEN * MAX_EXTRADATA_ITEMS);
> +
> + /* nt->sysdata_length will be used later to decide if the message
> + * needs to be fragmented.
> + * u
On Tue, Jan 14, 2025 at 05:45:46PM +0100, David Hildenbrand wrote:
> On 14.01.25 03:28, Dan Williams wrote:
> > Alistair Popple wrote:
> > > The procfs mmu files such as smaps and pagemap currently ignore devdax and
> > > fsdax pages because these pages are considered special. A future change
> > >
On Tue, Jan 14, 2025 at 03:59:31PM +0100, David Hildenbrand wrote:
> On 10.01.25 07:00, Alistair Popple wrote:
> > Zone device pages are used to represent various type of device memory
> > managed by device drivers. Currently compound zone device pages are
> > not supported. This is because MEMORY_
On Tue, Jan 14, 2025 at 09:44:38PM -0800, Dan Williams wrote:
> Alistair Popple wrote:
> [..]
> > > How does this case happen? I don't think any page would ever enter with
> > > both ->mapping and ->share set, right?
> >
> > Sigh. You're right - it can't. This patch series is getting a litte bit
On Thu, Jan 16, 2025 at 09:02:16PM +, Matthew Wilcox wrote:
> On Thu, Jan 16, 2025 at 12:02:34PM -0800, Paul E. McKenney wrote:
> > +The special cases where it makes sense do obtain a per-CPU pointer in
>
> s/do/to/
>
> > +preemptible code are addressed by raw_cpu_ptr(), but please note that
On Thu, Jan 16, 2025 at 12:02:34PM -0800, Paul E. McKenney wrote:
> +The special cases where it makes sense do obtain a per-CPU pointer in
s/do/to/
> +preemptible code are addressed by raw_cpu_ptr(), but please note that such
s/please note that //
> +use cases need to handle cases where two dif
Most of the this_cpu_*() operations may be used in preemptible code,
but not this_cpu_ptr(), and for good reasons. Therefore, better explain
the reasons and call out raw_cpu_ptr() as an alternative in certain very
special cases.
Signed-off-by: Paul E. McKenney
Cc: Jonathan Corbet
Cc: Peter Zijl
This series expands the XDP TX metadata framework to allow user
applications to pass per packet 64-bit launch time directly to the kernel
driver, requesting launch time hardware offload support. The XDP TX
metadata framework will not perform any clock conversion or packet
reordering.
Please note t
Enable Launch Time Control (LTC) support to XDP zero copy via XDP Tx
metadata framework.
This patch is tested with tools/testing/selftests/bpf/xdp_hw_metadata on
Intel I225-LM Ethernet controller. Below are the test steps and result.
Test Steps:
1. At DUT, start xdp_hw_metadata selftest applicati
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 Tiger Lake platform. Below are the test steps and result.
Test Steps:
1. At DUT, start xdp_hw_metadata selftest applica
Add launch time hardware offload request to xdp_hw_metadata. Users can
configure the delta of launch time relative to HW RX-time using the "-l"
argument. By default, the delta is set to 0 ns, which means the launch time
is disabled. By setting the delta to a non-zero value, the launch time
hardware
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 called launch time. The value of
launch time is communicated from user space to Ethernet driver via
launch_time f
Michael S. Tsirkin wrote:
> On Thu, Jan 16, 2025 at 05:08:03PM +0900, Akihiko Odaki wrote:
> > 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 t
On Wed, 15 Jan 2025 14:34:36 -0800
Dan Williams wrote:
> Ira Weiny wrote:
> > Dan Williams wrote:
> > > Ira Weiny wrote:
> >
> > [snip]
> >
> > > > diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
> > > > index
> > > > e8907c403edbd83c8a36b8d013c6bc3391207ee6..05a0718aea73b3b2a02
Hello Randy,
On Wed, Jan 15, 2025 at 02:56:06PM -0800, Randy Dunlap wrote:
> On 1/15/25 5:35 AM, Breno Leitao wrote:
> > Update the netconsole documentation to explain the new feature that
> > allows automatic population of the CPU number.
> >
> > The key changes include introducing a new section
On Thu, Jan 16, 2025 at 05:08:03PM +0900, Akihiko Odaki wrote:
> 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(
tun and tap implements the same vnet-related features so reuse the code.
Signed-off-by: Akihiko Odaki
---
drivers/net/Kconfig| 1 +
drivers/net/Makefile | 6 +-
drivers/net/tap.c | 152 +
drivers/net/tun_vnet.c | 5 ++
4 files chan
hdr_len is repeatedly used so keep it in a local variable.
Signed-off-by: Akihiko Odaki
---
drivers/net/tap.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index 061c2f27dfc8..7ee2e9ee2a89 100644
--- a/drivers/net/tap
tap_get_user() used to track the length of iov_iter with another
variable. We can use iov_iter_count() to determine the current length
to avoid such chores.
Signed-off-by: Akihiko Odaki
---
drivers/net/tap.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net
The vnet handling code will be reused by tap.
Signed-off-by: Akihiko Odaki
---
MAINTAINERS| 2 +-
drivers/net/Makefile | 3 +-
drivers/net/tun.c | 174 +---
drivers/net/tun_vnet.c | 175 +++
Decouple the vnet handling code so that we can reuse it for tap.
Signed-off-by: Akihiko Odaki
---
drivers/net/tun.c | 229 +++---
1 file changed, 133 insertions(+), 96 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index add09dfda
Decouple vnet-related functions from tun_struct so that we can reuse
them for tap in the future.
Signed-off-by: Akihiko Odaki
---
drivers/net/tun.c | 53 +++--
1 file changed, 27 insertions(+), 26 deletions(-)
diff --git a/drivers/net/tun.c b/driv
hdr_len is repeatedly used so keep it in a local variable.
Signed-off-by: Akihiko Odaki
---
drivers/net/tun.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index bd272b4736fb..ec56ac865848 100644
--- a/drivers/net/tun.c
+
tun_get_user() used to track the length of iov_iter with another
variable. We can use iov_iter_count() to determine the current length
to avoid such chores.
Signed-off-by: Akihiko Odaki
---
drivers/net/tun.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers
Check IS_ENABLED(CONFIG_TUN_VNET_CROSS_LE) to save some lines and make
future changes easier.
Signed-off-by: Akihiko Odaki
---
drivers/net/tun.c | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index e816aaba8e5
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_
28 matches
Mail list logo
