[netperf-dev] Controlling socket priority

[Amir Vadai]

Resending - because had troubles in my mail client.

It sets SO_PRIORITY and not IP_TOS - therefore, as you suspected, it 
only mucks with the internal queuing.


On 08/24/2011 09:43 PM, Dave Taht wrote:
> I am curious as to whether this really mucks with the TOS bits at all,
> especially on ipv6. I think it just mucks with the internal queuing.
>
> I tried various things to get ipv6 to do the right thing, perhaps I
> was on drugs? See:
>
> http://www.bufferbloat.net/issues/249
>
> On Wed, Aug 24, 2011 at 11:15 AM, Rick Jones<rick.jones2 at hp.com>  wrote:
>> On 08/14/2011 05:29 AM, Amir Vadai wrote:
>>> Attached a fixed patch.
>>>
>>> Now it will also compile when SO_PRIORITY is not defined.
>> Thanks. You have been very patient and I appreciate it.
>>
>> Now we come to the fun part.  By my calculations, the changes I made in the
>> top of trunk to actually report back transport layer retransmissions from
>> netserver's side occupied the last four bytes of the omni_response_struct or
>> more accurately, the overall 256 byte netperf control message size limit.
>>
>> So, that means bumping the size of the control message.  I've never held
>> that there would be inter-version support in netperf anyway but it has been
>> a long time since the last increase in control message size (at least I
>> think I've had a control message size increase in the past).
>>
>> rick jones
>>
>
>