On Tue, 12 Apr 2022 11:22:33 +0800, Jason Wang wrote:
>
> 在 2022/4/6 上午11:43, Xuan Zhuo 写道:
> > Separate the logic of split to create vring queue.
> >
> > This feature is required for subsequent virtuqueue reset vring.
> >
> > Signed-off-by: Xuan Zhuo
> > ---
> > drivers/virtio/virtio_ring.c |
On Tue, 12 Apr 2022 11:26:49 +0800, Jason Wang wrote:
>
> 在 2022/4/6 上午11:43, Xuan Zhuo 写道:
> > Separate the logic of creating desc_state, desc_extra, and subsequent
> > patches will call it independently.
> >
> > Signed-off-by: Xuan Zhuo
> > ---
> > drivers/virtio/virtio_ring.c | 53 ++
On Tue, 12 Apr 2022 11:31:08 +0800, Jason Wang wrote:
>
> 在 2022/4/6 上午11:43, Xuan Zhuo 写道:
> > Separate the logic of attach vring, subsequent patches will call it
> > separately.
> >
> > Signed-off-by: Xuan Zhuo
> > ---
> > drivers/virtio/virtio_ring.c | 20 ++--
> > 1 file ch
On Tue, 12 Apr 2022 13:53:44 +0800, Jason Wang wrote:
>
> 在 2022/4/6 上午11:43, Xuan Zhuo 写道:
> > virtio ring split supports resize.
> >
> > Only after the new vring is successfully allocated based on the new num,
> > we will release the old vring. In any case, an error is returned,
> > indicating t
On Tue, 12 Apr 2022 14:28:24 +0800, Jason Wang wrote:
>
> 在 2022/4/6 上午11:43, Xuan Zhuo 写道:
> > Separate the logic of packed to create vring queue.
> >
> > For the convenience of passing parameters, add a structure
> > vring_packed.
> >
> > This feature is required for subsequent virtuqueue reset
On Tue, 12 Apr 2022 15:07:58 +0800, Jason Wang wrote:
>
> 在 2022/4/6 上午11:43, Xuan Zhuo 写道:
> > This patch implements virtio pci support for QUEUE RESET.
> >
> > Performing reset on a queue is divided into these steps:
> >
> > 1. notify the device to reset the queue
> > 2. recycle the buffer s
On Tue, 12 Apr 2022 10:41:03 +0800, Jason Wang wrote:
>
> 在 2022/4/6 上午11:43, Xuan Zhuo 写道:
> > Record the maximum queue num supported by the device.
> >
> > virtio-net can display the maximum (supported by hardware) ring size in
> > ethtool -g eth0.
> >
> > When the subsequent patch implements vr
Hi Thomas,
On Tue, Apr 12, 2022 at 10:57 PM Thomas Gleixner wrote:
>
> On Tue, Apr 12 2022 at 19:27, Jason A. Donenfeld wrote:
> > +/**
> > + * random_get_entropy_fallback - Returns the raw clock source value,
> > + * used by random.c for platforms with no valid random_get_entropy().
> > + */
> >
On Tue, Apr 12 2022 at 19:27, Jason A. Donenfeld wrote:
> +/**
> + * random_get_entropy_fallback - Returns the raw clock source value,
> + * used by random.c for platforms with no valid random_get_entropy().
> + */
> +unsigned long random_get_entropy_fallback(void)
> +{
> + return tk_clock_read
On Tue, Apr 12, 2022 at 7:29 PM Jason A. Donenfeld wrote:
> In the event that random_get_entropy() can't access a cycle counter or
> similar, falling back to returning 0 is really not the best we can do.
> Instead, at least calling random_get_entropy_fallback() would be
> preferable, because that
In the event that random_get_entropy() can't access a cycle counter or
similar, falling back to returning 0 is really not the best we can do.
Instead, at least calling random_get_entropy_fallback() would be
preferable, because that always needs to return _something_, even
falling back to jiffies ev
In the event that random_get_entropy() can't access a cycle counter or
similar, falling back to returning 0 is really not the best we can do.
Instead, at least calling random_get_entropy_fallback() would be
preferable, because that always needs to return _something_, even
falling back to jiffies ev
In the event that random_get_entropy() can't access a cycle counter or
similar, falling back to returning 0 is really not the best we can do.
Instead, at least calling random_get_entropy_fallback() would be
preferable, because that always needs to return _something_, even
falling back to jiffies ev
In the event that random_get_entropy() can't access a cycle counter or
similar, falling back to returning 0 is really not the best we can do.
Instead, at least calling random_get_entropy_fallback() would be
preferable, because that always needs to return _something_, even
falling back to jiffies ev
In the event that random_get_entropy() can't access a cycle counter or
similar, falling back to returning 0 is really not the best we can do.
Instead, at least calling random_get_entropy_fallback() would be
preferable, because that always needs to return _something_, even
falling back to jiffies ev
In the event that random_get_entropy() can't access a cycle counter or
similar, falling back to returning 0 is really not the best we can do.
Instead, at least calling random_get_entropy_fallback() would be
preferable, because that always needs to return _something_, even
falling back to jiffies ev
In the event that random_get_entropy() can't access a cycle counter or
similar, falling back to returning 0 is really not the best we can do.
Instead, at least calling random_get_entropy_fallback() would be
preferable, because that always needs to return _something_, even
falling back to jiffies ev
In the event that random_get_entropy() can't access a cycle counter or
similar, falling back to returning 0 is really not the best we can do.
Instead, at least calling random_get_entropy_fallback() would be
preferable, because that always needs to return _something_, even
falling back to jiffies ev
In the event that random_get_entropy() can't access a cycle counter or
similar, falling back to returning 0 is really not the best we can do.
Instead, at least calling random_get_entropy_fallback() would be
preferable, because that always needs to return _something_, even
falling back to jiffies ev
The addition of random_get_entropy_fallback() provides access to
whichever time source has the highest frequency, which is useful for
gathering entropy on platforms without available cycle counters. It's
not necessarily as good as being able to quickly access a cycle counter
that the CPU has, but i
Hi folks,
The RNG uses a function called random_get_entropy() basically anytime
that it needs to timestamp an event. For example, an interrupt comes in,
and we mix a random_get_entropy() into the entropy pool somehow.
Somebody mashes their keyboard or moves their mouse around? We mix a
random_get_
在 2022/4/6 上午11:43, Xuan Zhuo 写道:
Use virtqueue_get_vring_max_size() in virtnet_get_ringparam() to set
tx,rx_max_pending.
Signed-off-by: Xuan Zhuo
---
Acked-by: Jason Wang
drivers/net/virtio_net.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net
在 2022/4/6 上午11:43, Xuan Zhuo 写道:
Use virtio_find_vqs_ctx_size() to specify the maximum ring size of tx,
rx at the same time.
| rx/tx ring size
---
speed == UNKNOWN or < 10G| 1024
speed < 40G | 4096
speed >= 40G
在 2022/4/6 上午11:43, Xuan Zhuo 写道:
Introduce helper virtio_find_vqs_ctx_size() to call find_vqs and specify
the maximum size of each vq ring.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
include/linux/virtio_config.h | 12
1 file changed, 12 insertions(+)
diff --git
在 2022/4/6 上午11:43, Xuan Zhuo 写道:
Virtio MMIO support the new parameter sizes of find_vqs().
Signed-off-by: Xuan Zhuo
---
Acked-by: Jason Wang
drivers/virtio/virtio_mmio.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/virtio/virtio_mmio.c b/drive
在 2022/4/6 上午11:43, Xuan Zhuo 写道:
Virtio PCI supports new parameter sizes of find_vqs().
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/virtio/virtio_pci_common.c | 18 ++
drivers/virtio/virtio_pci_common.h | 1 +
drivers/virtio/virtio_pci_legacy.c | 6 +
在 2022/4/6 上午11:43, Xuan Zhuo 写道:
find_vqs() adds a new parameter sizes to specify the size of each vq
vring.
0 means use the maximum size supported by the backend.
Does this mean driver still need to prepare a array of 0 or it can
simply pass NULL to find_vqs()?
Thanks
In the split s
在 2022/4/6 上午11:43, Xuan Zhuo 写道:
This patch implements virtio pci support for QUEUE RESET.
Performing reset on a queue is divided into these steps:
1. notify the device to reset the queue
2. recycle the buffer submitted
3. reset the vring (may re-alloc)
4. mmap vring to device, and en
28 matches
Mail list logo
