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. > > I just figured it's a bit weird to return >0 here in flush(). > > > > > (2) is not a problem, but I fail to see how useful that would be. Is > > the idea manually keeping track of flush happening? > > Yes if we can check this up it'll be good enough to me. The trace point > could help in some case in the future too to monitor the behavior of kernel > MSG_ERRQUEUE but if you don't like it then it's okay. > TBH I am not sure how those traces work yet, and I am afraid it can introduce some overhead in flush. In any way, we can introduce this trace in a separated patch, since fixing zero-copy flush seems more urgent right now. Best regards, Leo > -- > Peter Xu >
