Hello Catalin,
Sunday, June 15, 2014, 4:08:15 PM, you wrote:
>>>>> I would like to request two changes before release.
>>>>> - An option to restrict the size of packets over automatic detection of
>>>>> MTU.
>>>> You mean like if the MTU is 9000, you want the ability to tell the
>>>> vblade to act like it's smaller, right?
>> CS> Yes. That's the gist of it.
>> CS> I believe there is some value in the ability to manually tweak the
>> CS> maximum packet size used by vlade.
>> But its all to initiator side. Actually for example WinAoE (and its
>> forks ;) ) does MTU 'autodetection' instead of using Conf::scnt.
>>
CS> That's not entirely correct.
CS> WinAoE indeed does a form of negotiation there - it will start at
CS> (MTU/sector size) and will do reads of decreasing size, until it
CS> receives a valid packet.
CS> However! If you would kindly check ata.c:157 (on v22-rc1) any ATA
CS> request for more than the supported packet size will be refused.
That's also not entirely correct :) It increases sectors count from
1 to ether MTU limit, either any kind of error from target, including
timeout.
However in my investigation I found that its usefull for initiator to
know also value called in vblade as 'buffers count' .. I mean such
a count of packets initiator can send to target knowing that it will
likely process them all. Because sending more request than this value
as 'outstanding' sharply increases drops (and resends) rate.
I implemented also kind of negotiation to detect this by sending
'congestion' extension command that does usleep(500000) and the
responds for all commands received in buffer. Such approach by
comparing with directly asking target for buffers count will
detect also any implicit buffering between initiator and target
--
Best regards,
Killer{R} mailto:support@xxxxxxxxxxxx
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Aoetools-discuss mailing list
Aoetools-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
