X-Sylpheed-Account-Id:2
S:andy.sharp@lsi.com
SCF:#mh/Mailbox/sent
X-Sylpheed-Sign:0
X-Sylpheed-Encrypt:0
X-Sylpheed-Privacy-System:
RMID:#imap/LSI/INBOX	0	4A985CD1.3010306@lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 28 Aug 2009 15:48:25 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: William Fisher <bfisher@lsi.com>
Subject: Re: SSC merge/no-merge analysis
Message-ID: <20090828154825.7a52ab67@ripper.onstor.net>
References: <20090828121014.1978d9ca@ripper.onstor.net>
	<4A985CD1.3010306@lsi.com>
Organization: LSI
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 28 Aug 2009 16:40:17 -0600 William Fisher <bfisher@lsi.com>
wrote:

> Andrew Sharp wrote:
> > I sat down and did a bit of analysis, and the decision is starting
> > to look obvious.  Attached is a little document I wrote up.  We
> > need to make sure this decision is well communicated so that there
> > is no confusion in other camps.
> > 
> > I will begin updating the design document to lay out the new virtual
> > server design for tuxstor, since it will necessarily be different
> > from tuxrx.
> > 
> 
> In the Not Merging SSC column, we see:
> 
> > neteee networking code has to be written to handle packet fragments,
> >   forwarding, etc.  then thrown away for a merged ssc product
> 
> 
> The NETEEE protocol code already handle's fragments and the
> eee forwarding code does like-wise. hence this is a NON task
> and doesn't need to be thrown away in either case.

So you're saying you're done with that and it doesn't need to be
counted, or am I missing something?

> Since the Merging SSC column is mostly removing the
> RCON and MGMT bus drivers and reworking the eee forwarding
> code to make everything local, this is a pretty bounded task.
> I woould guess maybe 1 week.
> 
> The RMC issue goes away since you can convert the implementation
> to use local sockets and ditch all the rest. This is a major
> simplification in the code and well worth the effort.
> This is probably a 2 week task.

RMC is still needed to communicate between cluster nodes, and therefore
not immediately throw-able-away-able.  Much as I would loooove to.

> I think what is missing in the Merging SSC column on COUGAR
> hardware, I presume, is the IPC scheme to the 8 TuxStor
> linux instance. This still requires using the mgmtbus driver
> so what is saved here?

Can you elaborate more because I'm not sure what you're referring to by
"IPC scheme".  The mgmt-bus driver is a pseudo driver on top of the PCI
bus between the TXRX and the SSC only.  So it would be gone.

> I think the only real work here is writing the TuxStor
> Linux daemon's that communicate with the existing SSC
> code. Not doing this merge under Cougar hardware is
> a major win IMHO, since the amount of integration is
> reduced since the messaging works now and only the
> TuxStor server daemons need to be written. Since
> we already have the txrx register function code,
> that runs out of the polling loop, this can not be
> a big deal. We have working code today, all we need
> to do is convert it to Linux rather than EEE.

Writing the new userspace daemon to handle all the messages coming
across the mgmt-bus and doing something with them is a decent amount of
effort.  Which is largely or completely throw away.

> Hence the decision is independent of the two stage
> porting effort, Cougar first, x86 second so
> I assume the plan of record is Not Merge on the
> Cougar and Merge on the x86.
> 
> Later,
> 
> -- Bill
