On Wed, Jun 08, 2022 at 03:14:36PM -0300, Leonardo Bras Soares Passos wrote:
> On Wed, Jun 8, 2022 at 8:41 AM Peter Xu <pet...@redhat.com> wrote:
> >
> > On Wed, Jun 08, 2022 at 02:37:28AM -0300, Leonardo Bras Soares Passos wrote:
> > > (1) is not an option, as the interface currently uses ret=1 to make
> > > sure MSG_ZEROCOPY is getting used,
> > > I added that so the user of qio_channel can switch off zero-copy if
> > > it's not getting used, and save some cpu.
> >
> > Yes (1) is not, but could you explain what do you mean by making sure
> > MSG_ZEROCOPY being used? Why is it relevant to the retval here?
>
> If sendmsg() is called with MSG_ZEROCOPY, and everything is configured
> correctly, the kernel will attempt to send the buffer using zero-copy.
>
> Even with the right configuration on a recent enough kernel, there are
> factors that can prevent zero-copy from happening, and the kernel will
> fall back to the copying mechanism.
> An example being the net device not supporting 'Scatter-Gather'
> feature (NETIF_F_SG).
>
> When this happens, there is an overhead for 'trying zero-copy first',
> instead of just opting for the copying mechanism.
>
> In a previous iteration of the patchset, it was made clear that it's
> desirable to detect when the kernel falls back to copying mechanism,
> so the user of 'QIOChannelSocket' can switch to copying and avoid the
> overhead. This was done by the return value of flush(), which is 1 if
> that occurs.
Two questions..
1) When that happens, will MSG_ERRQUEUE keeps working just like zerocopy
is functional?
If the answer is yes, I don't see how ret=1 will ever be
returned.. because we'll also go into the same loop in
qio_channel_socket_flush() anyway.
If the answer is no, then since we'll have non-zero zero_copy_queued,
will the loop in qio_channel_socket_flush() go into a dead one? How
could it return?
2) Even if we have the correct ret=1 returned when that happens, which
caller is detecting that ret==1 and warn the admin?
Thanks,
--
Peter Xu
