On 15/06/2014 2:48 PM, Killer{R} wrote:
> Hello Catalin,
>
> Sunday, June 15, 2014, 6:59:54 AM, 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.
>
That's not entirely correct.
WinAoE indeed does a form of negotiation there - it will start at
(MTU/sector size) and will do reads of decreasing size, until it
receives a valid packet.
However! If you would kindly check ata.c:157 (on v22-rc1) any ATA
request for more than the supported packet size will be refused.
Legacy note:
Negotiation is, I believe, a reminiscence from before the Query Config
Information 'Sector Count' field was added, in AoEr9.
But I would argue that this was invalid behaviour in AoEr8 (and maybe
previously. I was unable to find previous revisions. @Ed some help here?)
While there was no outright ban on it up-front (it was only textually
explained that a standard 1520 byte MTU would limit device ATA commands
to two sectors, and servers were not required to understand emitted ATA
commands), the ATA 'Sector Count' is explicitly constrained to 0, 1 or 2.
This effectively makes negotiating larger sector counts invalid. Both in
method and in result.
The code does, however, have the nice side effect of Path MTU Detection,
if, for example, your networking equipment is not configured or capable
of handling jumbo frames (or, who knows, some weird networking equipment
that takes RFC791 at the minimum, and has a maximum supported datagram
size as low as 68 bytes. :) )
Cheers!
------------------------------------------------------------------------------
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
