Understood.
As I said, my suspicion is that the original author wanted to reuse the
receive buffer for the response and was using this sector count as a method
of ensuring that the buffer was big enough because the client driver will
set this to 1 but also send additional data as if it was accessing 2
sectors worth of data. But the way the blade server software carves up
memory it doesn't need this additional "tweak" because the buffers being
received into are already full size buffers. In my driver I just set it to
1 and I don't send additional data and it works fine.. It just surprised me
when I additionally had this set to zero and things would error out.
David
On Mon, Oct 7, 2013 at 10:37 AM, Ed Cashin <ecas...@coraid.com> wrote:
> Yes, folks at Coraid wrote the original vblade. I can't remember a good
> reason for the check you're asking about. I thought maybe it was just done
> by accident (forgetting the AoE spec) to support another part of the vblade
> code that relies on the sector count being accurate, but I haven't had a
> chance to check on that yet.
>
> On Oct 7, 2013, at 11:09 AM, David Leach wrote:
>
> > Ed,
> >
> > Did Coraid write the original vblade code? If so, do they have any
> insight on why the blade code was written to require the sector field to
> have a 1?
> >
> > David
> >
> >
> > On Thu, Oct 3, 2013 at 8:55 PM, David Leach <tas...@gmail.com> wrote:
> > Ed,
> >
> > Well on the surface if you are doing a client side AoE driver you would
> look at the ATA spec and decide that all the N/A values can be just set to
> zero. Which is what I did but immediately got a bad arguments error from
> the blade server. When you look at the blade server code it does this test
> for "1" for no apparent reason.
> >
> > My initial suspicion was that the blade code was wanting to reuse the
> packet that it received the request on and as such wanted to make sure it
> was big enough by having the client set the sector count to 1 and further
> adding some noop data to the request packet. But looking at the blade code
> the way it carves up packet buffers it didn't need to do that so it is
> unclear why it is even in there.
> >
> > From my perspective, it is unneeded and actually complicates things
> because the AoE spec implies that you are just supposed to map the ATA
> commands and registers on to the request without doing any special
> modifications... which isn't true in this particular case. I've not seen
> what a normal SATA request for ID would look like from a HD perspective but
> I suspect they don't even set those register values and may even
> potentially just set them all to zero.
> >
> > I popped the question on this discussion board to see if I'm missing
> something.
> >
> > David
> >
> >
> > On Thu, Oct 3, 2013 at 7:29 PM, Ed Cashin <ecas...@coraid.com> wrote:
> > On Oct 3, 2013, at 2:36 PM, David Leach wrote:
> >
> > > Can someone explain why the ATA command Identify Device (0xEC) has the
> following test in the switch statement:
> > >
> > > case 0xec: // identify device
> > > if (p->sectors != 1 || ndp < 512)
> > > return -1;
> > >
> > >
> > > Given that the ATA spec says that the sector register is N/A (as are
> pretty much all the rest) when making this command I don't know why the
> blade server requires that submission of this command have AoE ATA command
> set sector to 1?
> > >
> > > I have my suspicions but I would like to hear from others...
> >
> > What are your suspicions? Looking at ATA 6 draft rev. 3b section 18.5 I
> see also see that sector count is NA on input.
> >
> > --
> > Ed Cashin
> > ecas...@coraid.com
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> > the latest Intel processors and coprocessors. See abstracts and register
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk_______________________________________________
> > Aoetools-discuss mailing list
> > Aoetools-discuss@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
>
> --
> Ed Cashin
> ecas...@coraid.com
>
>
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Aoetools-discuss mailing list
Aoetools-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
