On Fri, Sep 20, 2024 at 05:23:20PM +0200, Maciej S. Szmigiero wrote:
> On 19.09.2024 23:17, Peter Xu wrote:
> > On Thu, Sep 19, 2024 at 09:49:43PM +0200, Maciej S. Szmigiero wrote:
> > > On 10.09.2024 21:48, Peter Xu wrote:
> > > > On Wed, Aug 28, 2024 at 09:41:17PM -0300, Fabiano Rosas wrote:
> >
On 19.09.2024 23:17, Peter Xu wrote:
On Thu, Sep 19, 2024 at 09:49:43PM +0200, Maciej S. Szmigiero wrote:
On 10.09.2024 21:48, Peter Xu wrote:
On Wed, Aug 28, 2024 at 09:41:17PM -0300, Fabiano Rosas wrote:
+size_t multifd_device_state_payload_size(void)
+{
+return sizeof(MultiFDDeviceState
On Thu, Sep 19, 2024 at 09:49:57PM +0200, Maciej S. Szmigiero wrote:
> On 10.09.2024 18:06, Peter Xu wrote:
> > On Tue, Aug 27, 2024 at 07:54:31PM +0200, Maciej S. Szmigiero wrote:
> > > +bool multifd_queue_device_state(char *idstr, uint32_t instance_id,
> > > +char
On Thu, Sep 19, 2024 at 09:49:43PM +0200, Maciej S. Szmigiero wrote:
> On 10.09.2024 21:48, Peter Xu wrote:
> > On Wed, Aug 28, 2024 at 09:41:17PM -0300, Fabiano Rosas wrote:
> > > > +size_t multifd_device_state_payload_size(void)
> > > > +{
> > > > +return sizeof(MultiFDDeviceState_t);
> > > >
On 17.09.2024 19:50, Peter Xu wrote:
On Tue, Sep 17, 2024 at 07:07:10PM +0200, Cédric Le Goater wrote:
[ ... ]
I as a patch writer always like to do that when it's essential. Normally
the case is I don't have enough reviewer resources to help me get a better
design, or discuss about it.
Rig
On 9.09.2024 21:40, Peter Xu wrote:
On Fri, Aug 30, 2024 at 10:02:40AM -0300, Fabiano Rosas wrote:
@@ -397,20 +404,16 @@ bool multifd_send(MultiFDSendData **send_data)
p = &multifd_send_state->params[i];
/*
- * Lockless read to p->pending_job is safe, because o
On 10.09.2024 18:06, Peter Xu wrote:
On Tue, Aug 27, 2024 at 07:54:31PM +0200, Maciej S. Szmigiero wrote:
+bool multifd_queue_device_state(char *idstr, uint32_t instance_id,
+char *data, size_t len)
+{
+/* Device state submissions can come from multiple thread
On 10.09.2024 21:48, Peter Xu wrote:
On Wed, Aug 28, 2024 at 09:41:17PM -0300, Fabiano Rosas wrote:
+size_t multifd_device_state_payload_size(void)
+{
+return sizeof(MultiFDDeviceState_t);
+}
This will not be necessary because the payload size is the same as the
data type. We only need it
On Tue, Sep 17, 2024 at 07:07:10PM +0200, Cédric Le Goater wrote:
> [ ... ]
>
> > > > I as a patch writer always like to do that when it's essential.
> > > > Normally
> > > > the case is I don't have enough reviewer resources to help me get a
> > > > better
> > > > design, or discuss about it.
[ ... ]
I as a patch writer always like to do that when it's essential. Normally
the case is I don't have enough reviewer resources to help me get a better
design, or discuss about it.
Right, but we can't keep providing a moving target. See the thread pool
discussion for an example. It's hard
On Fri, Sep 13, 2024 at 03:26:43PM -0300, Fabiano Rosas wrote:
> The thread-pool approach is being looked at to solve this particular
> problem, but we have also discussed in the past that multifd threads
> themselves should be managed by a thread pool. Will we add this
> requirement to what is bei
Peter Xu writes:
> On Fri, Sep 13, 2024 at 12:04:00PM -0300, Fabiano Rosas wrote:
>> Peter Xu writes:
>>
>> > On Fri, Sep 13, 2024 at 10:21:39AM -0300, Fabiano Rosas wrote:
>> >> Peter Xu writes:
>> >>
>> >> > On Thu, Sep 12, 2024 at 03:43:39PM -0300, Fabiano Rosas wrote:
>> >> >> Peter Xu w
On Fri, Sep 13, 2024 at 12:04:00PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Fri, Sep 13, 2024 at 10:21:39AM -0300, Fabiano Rosas wrote:
> >> Peter Xu writes:
> >>
> >> > On Thu, Sep 12, 2024 at 03:43:39PM -0300, Fabiano Rosas wrote:
> >> >> Peter Xu writes:
> >> >>
> >> >> Hi P
Peter Xu writes:
> On Fri, Sep 13, 2024 at 10:21:39AM -0300, Fabiano Rosas wrote:
>> Peter Xu writes:
>>
>> > On Thu, Sep 12, 2024 at 03:43:39PM -0300, Fabiano Rosas wrote:
>> >> Peter Xu writes:
>> >>
>> >> Hi Peter, sorry if I'm not very enthusiastic by this, I'm sure you
>> >> understand t
On Fri, Sep 13, 2024 at 10:21:39AM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Thu, Sep 12, 2024 at 03:43:39PM -0300, Fabiano Rosas wrote:
> >> Peter Xu writes:
> >>
> >> Hi Peter, sorry if I'm not very enthusiastic by this, I'm sure you
> >> understand the rework is a little frustr
Peter Xu writes:
> On Thu, Sep 12, 2024 at 03:43:39PM -0300, Fabiano Rosas wrote:
>> Peter Xu writes:
>>
>> Hi Peter, sorry if I'm not very enthusiastic by this, I'm sure you
>> understand the rework is a little frustrating.
>
> That's OK.
>
> [For some reason my email sync program decided to g
On Thu, Sep 12, 2024 at 03:43:39PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> Hi Peter, sorry if I'm not very enthusiastic by this, I'm sure you
> understand the rework is a little frustrating.
That's OK.
[For some reason my email sync program decided to give up working for
hours. I g
Peter Xu writes:
Hi Peter, sorry if I'm not very enthusiastic by this, I'm sure you
understand the rework is a little frustrating.
> On Wed, Aug 28, 2024 at 09:41:17PM -0300, Fabiano Rosas wrote:
>> > +size_t multifd_device_state_payload_size(void)
>> > +{
>> > +return sizeof(MultiFDDeviceSt
On Wed, Aug 28, 2024 at 09:41:17PM -0300, Fabiano Rosas wrote:
> > +size_t multifd_device_state_payload_size(void)
> > +{
> > +return sizeof(MultiFDDeviceState_t);
> > +}
>
> This will not be necessary because the payload size is the same as the
> data type. We only need it for the special cas
On Tue, Aug 27, 2024 at 07:54:31PM +0200, Maciej S. Szmigiero wrote:
> +bool multifd_queue_device_state(char *idstr, uint32_t instance_id,
> +char *data, size_t len)
> +{
> +/* Device state submissions can come from multiple threads */
> +QEMU_LOCK_GUARD(&que
On Fri, Aug 30, 2024 at 10:02:40AM -0300, Fabiano Rosas wrote:
> >>> @@ -397,20 +404,16 @@ bool multifd_send(MultiFDSendData **send_data)
> >>>
> >>> p = &multifd_send_state->params[i];
> >>> /*
> >>> - * Lockless read to p->pending_job is safe, because only multifd
>
"Maciej S. Szmigiero" writes:
> On 29.08.2024 02:41, Fabiano Rosas wrote:
>> "Maciej S. Szmigiero" writes:
>>
>>> From: "Maciej S. Szmigiero"
>>>
>>> A new function multifd_queue_device_state() is provided for device to queue
>>> its state for transmission via a multifd channel.
>>>
>>> Signed
On 29.08.2024 02:41, Fabiano Rosas wrote:
"Maciej S. Szmigiero" writes:
From: "Maciej S. Szmigiero"
A new function multifd_queue_device_state() is provided for device to queue
its state for transmission via a multifd channel.
Signed-off-by: Maciej S. Szmigiero
---
include/migration/misc.
"Maciej S. Szmigiero" writes:
> From: "Maciej S. Szmigiero"
>
> A new function multifd_queue_device_state() is provided for device to queue
> its state for transmission via a multifd channel.
>
> Signed-off-by: Maciej S. Szmigiero
> ---
> include/migration/misc.h | 4 ++
> migration/m
From: "Maciej S. Szmigiero"
A new function multifd_queue_device_state() is provided for device to queue
its state for transmission via a multifd channel.
Signed-off-by: Maciej S. Szmigiero
---
include/migration/misc.h | 4 ++
migration/meson.build| 1 +
migration/multifd-
25 matches
Mail list logo
