On Thu, 26 Apr 2018, Sebastian Moeller wrote:
On Apr 26, 2018, at 09:26, Jonathan Morton wrote:
Genuine question: I have a superpacket circa 64K, this is a lump of data in a
tcp flow. I have another small VOIP packet, it’s latency sensitive. If I
split the super
> I really liked you initial idea to make the threshold when to segment a
> superpacket based on the duration that packet would hogg the wire/shaper, as
> that gives an intuitive feel for the worst case inter-flow latency induced.
> Especially this would allow on many links intermediate sized
I thought the discussion was only about GSO/TSO. Also, isn't GRO/LRO
incompatible with routing? Anyway, I was just supporting your
interpretation of what Eric potentially means.
/Jonas
On Thu, Apr 26, 2018 at 10:55 AM, Toke Høiland-Jørgensen
wrote:
> Jonas Mårtensson
Jonas Mårtensson writes:
> "I *think* that what Eric means is that the GSO logic should automatically
> size the GSO superpackets so the latency cost is negligible for the actual
> link rate."
>
> Something like this?
>
> https://lwn.net/Articles/564979/
>
>
--- Begin Message ---
> On 26 Apr 2018, at 08:26, Jonathan Morton wrote:
>
>> Genuine question: I have a superpacket circa 64K, this is a lump of data in
>> a tcp flow. I have another small VOIP packet, it’s latency sensitive. If I
>> split the super packet into
Kevin Darbyshire-Bryant writes:
>> On 25 Apr 2018, at 21:45, Toke Høiland-Jørgensen wrote:
>>
>> For those who have not been following the discussion on the upstreaming
>> patches, here's an update:
>>
>>
>>
>> So please do test the current git
> Genuine question: I have a superpacket circa 64K, this is a lump of data in
> a tcp flow. I have another small VOIP packet, it’s latency sensitive. If I
> split the super packet into individual 1.5K packets as they would be on the
> wire, I can insert my VOIP packet at suitable place in
Ryan Mounce writes:
>> On 26 Apr 2018, at 16:09, Toke Høiland-Jørgensen wrote:
>>
>> Ryan Mounce writes:
>>
>>> I'll investigate making the ACK filtering code safe, it is my mess after
>>> all :)
>>>
>>> Eric obviously understands this
> On 26 Apr 2018, at 16:09, Toke Høiland-Jørgensen wrote:
>
> Ryan Mounce writes:
>
>> I'll investigate making the ACK filtering code safe, it is my mess after all
>> :)
>>
>> Eric obviously understands this stuff a lot better than me, it looks
>> like there
Ryan Mounce writes:
> I'll investigate making the ACK filtering code safe, it is my mess after all
> :)
>
> Eric obviously understands this stuff a lot better than me, it looks
> like there are two issues?
> - Lack of minimum length check for TCP header, should be fairly
>
On Wed, Apr 25, 2018 at 6:32 PM, Stephen Hemminger
wrote:
> On Thu, 26 Apr 2018 10:40:29 +0930
> Ryan Mounce wrote:
>
>> I'll investigate making the ACK filtering code safe, it is my mess after all
>> :)
>>
>> Eric obviously understands this stuff
On Thu, 26 Apr 2018 10:40:29 +0930
Ryan Mounce wrote:
> I'll investigate making the ACK filtering code safe, it is my mess after all
> :)
>
> Eric obviously understands this stuff a lot better than me, it looks
> like there are two issues?
> - Lack of minimum length check
I'll investigate making the ACK filtering code safe, it is my mess after all :)
Eric obviously understands this stuff a lot better than me, it looks
like there are two issues?
- Lack of minimum length check for TCP header, should be fairly
straight-forward to fix
- The possibility of unsafely
For those who have not been following the discussion on the upstreaming
patches, here's an update:
- I've just pushed patches to only split GSO packets when shaping below
one gigabit; and hopefully made the overhead compensation code deal
gracefully with GSO packets if someone for some reason
14 matches
Mail list logo