> On May 28, 2019, at 2:44 PM, Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx> wrote: >> It also appears that other TX CMSG types cause similar issues, for >> example trying to set SOL_IP/IP_TOS. > > See previous comment in v2 > > http://patchwork.ozlabs.org/patch/1105564/ > Sorry, missed those updates. I am still relying too much on my emails. Will fix for next version, and will scrub through messages on patchwork. > FYI, no need for a cover letter for a single patch. Also, I think the > cc list can be more concise. Mainly netdev. Fixed. > Same as above. This is not about zerocopy. > Will fix next patchset. > Asked elsewhere, but best answered here: given that xmit_more delays > delivery to the NIC until the last segment in a train, is the first > segment in your opinion still the best to attach the timestamp request > to? > > To reiterate, we do not want to need a follow-up patch to disable > xmit_more when timestamps are requested. > I think it would be worthwhile. I was playing with this patch … + /* software TX timeststamps are sent immediately */ + if (tsflags & SKBTX_SW_TSTAMP) + seg->xmit_more = 0; … which attempts to address this issue. I believe that the patch should be applied for software timestamps only. However when I applied in net-next I got the following compile error, which suggests there is more investigation needed, and therefore requires a separate patch. net/ipv4/udp_offload.c: In function ‘__udp_gso_segment’: net/ipv4/udp_offload.c:251:7: error: ‘struct sk_buff’ has no member named ‘xmit_more’ seg->xmit_more = 0;
