On Sun, May 26, 2019 at 8:30 PM Willem de Bruijn
wrote:
>
> On Sat, May 25, 2019 at 1:47 PM Fred Klassen wrote:
> >
> >
> >
> > > On May 25, 2019, at 8:20 AM, Willem de Bruijn
> > > wrote:
> > >
> > > On Fri, May 24, 2019 at 6:01 PM Fred Klassen wrote:
> > >>
> > >>
> > >>
> > >>> On May 24,
On Sat, May 25, 2019 at 1:47 PM Fred Klassen wrote:
>
>
>
> > On May 25, 2019, at 8:20 AM, Willem de Bruijn
> > wrote:
> >
> > On Fri, May 24, 2019 at 6:01 PM Fred Klassen wrote:
> >>
> >>
> >>
> >>> On May 24, 2019, at 12:29 PM, Willem de Bruijn
> >>> wrote:
> >>>
> >>> It is the last
> On May 23, 2019, at 2:59 PM, Willem de Bruijn
> wrote:what exactly is the issue with IP_TOS?
>
> If I understand correctly, the issue here is that the new 'P' option
> that polls on the error queue times out. This is unrelated to
> specifying TOS bits? Without zerocopy or timestamps, no
> On May 23, 2019, at 2:39 PM, Willem de Bruijn
> wrote:
> Zerocopy notification reference count is managed in skb_segment. That
> should work.
>
I’m trying to understand the context of reference counting in skb_segment. I
assume that
there is an opportunity to optimize the count of
> On May 23, 2019, at 2:59 PM, Willem de Bruijn
> wrote:
> what exactly is the issue with IP_TOS?
>
> If I understand correctly, the issue here is that the new 'P' option
> that polls on the error queue times out. This is unrelated to
> specifying TOS bits? Without zerocopy or timestamps, no
> On May 25, 2019, at 8:20 AM, Willem de Bruijn
> wrote:
>
> On Fri, May 24, 2019 at 6:01 PM Fred Klassen wrote:
>>
>>
>>
>>> On May 24, 2019, at 12:29 PM, Willem de Bruijn
>>> wrote:
>>>
>>> It is the last moment that a timestamp can be generated for the last
>>> byte, I don't see
On Fri, May 24, 2019 at 6:01 PM Fred Klassen wrote:
>
>
>
> > On May 24, 2019, at 12:29 PM, Willem de Bruijn
> > wrote:
> >
> > It is the last moment that a timestamp can be generated for the last
> > byte, I don't see how that is "neither the start nor the end of a GSO
> > packet”.
>
> My
> On May 24, 2019, at 12:29 PM, Willem de Bruijn
> wrote:
>
> It is the last moment that a timestamp can be generated for the last
> byte, I don't see how that is "neither the start nor the end of a GSO
> packet”.
My misunderstanding. I thought TCP did last segment timestamping, not
last
On Fri, May 24, 2019 at 12:34 PM Fred Klassen wrote:
>
> > Interesting. TCP timestamping takes the opposite choice and does
> > timestamp the last byte in the sendmsg request.
> >
>
> I have a difficult time with the philosophy of TX timestamping the last
> segment. The actual timestamp occurs
> Interesting. TCP timestamping takes the opposite choice and does
> timestamp the last byte in the sendmsg request.
>
I have a difficult time with the philosophy of TX timestamping the last
segment. The actual timestamp occurs just before the last segment
is sent. This is neither the start nor
On Thu, May 23, 2019 at 9:38 PM Fred Klassen wrote:
>
> > Thanks for the report.
> >
> > Zerocopy notification reference count is managed in skb_segment. That
> > should work.
> >
> > Support for timestamping with the new GSO feature is indeed an
> > oversight. The solution is similar to how TCP
> Thanks for the report.
>
> Zerocopy notification reference count is managed in skb_segment. That
> should work.
>
> Support for timestamping with the new GSO feature is indeed an
> oversight. The solution is similar to how TCP associates the timestamp
> with the right segment in
On Thu, May 23, 2019 at 5:09 PM Fred Klassen wrote:
>
> Fixes an issue where TX Timestamps are not arriving on the error queue
> when UDP_SEGMENT CMSG type is combined with CMSG type SO_TIMESTAMPING.
> This can be illustrated with an updated updgso_bench_tx program which
> includes the '-T'
On Thu, May 23, 2019 at 5:09 PM Fred Klassen wrote:
>
> Fixes an issue where TX Timestamps are not arriving on the error queue
> when UDP_SEGMENT CMSG type is combined with CMSG type SO_TIMESTAMPING.
> This can be illustrated with an updated updgso_bench_tx program which
> includes the '-T'
Fixes an issue where TX Timestamps are not arriving on the error queue
when UDP_SEGMENT CMSG type is combined with CMSG type SO_TIMESTAMPING.
This can be illustrated with an updated updgso_bench_tx program which
includes the '-T' option to test for this condition.
./udpgso_bench_tx -4ucTPv -S
15 matches
Mail list logo