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	7135	861DA0537719934884B3D30A2666FECC010B98C96A@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 20 Oct 2009 15:23:45 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Kozlovsky, Maxim" <Maxim.Kozlovsky@lsi.com>
Cc: "Fong, Rendell" <Rendell.Fong@lsi.com>, "Stark, Brian"
 <Brian.Stark@lsi.com>, "Fisher, Bill" <Bill.Fisher@lsi.com>, "Ariyamannil,
 Jobi" <Jobi.Ariyamannil@lsi.com>, "Vandever, Chris"
 <Chris.Vandever@lsi.com>
Subject: Re: description of virtual server changes
Message-ID: <20091020152345.26f5b152@ripper.onstor.net>
References: <1255973717.20354.112.camel@rendellf>
 <861DA0537719934884B3D30A2666FECC010B98C96A@cosmail02.lsi.com>
Organization: LSI
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 20 Oct 2009 13:11:17 -0600 "Kozlovsky, Maxim"
<Maxim.Kozlovsky@lsi.com> wrote:

First thing to keep in mind is that this is not for Orion, so there is
no service VM.  We aren't trying to design for that, and the
architecture document for that doesn't state how any of that will work,
nor is MXA a concrete part of Orion, so we can't implement to that
either.

We are strictly implementing for a converged environment filer, not
Orion or MXA or VMs.  Since those are rapidly moving targets that might
not ever ship in our lifetimes, there's no percentage in trying to hit
them.

> Hello,
> 
> 1. No merging of txrx ipm functionality in VSD. According to the
> architecture document, the MXA is expected to be running on the
> service VM. The MXA is going to eventually subsume most of the VSD
> functionality. Even though in the intermediate testing variant the
> VSD and the txrx will be co-located, it is not going to always be so. 

Yes, it will be merged into the vserver daemon.  That architecture
document doesn't apply to this phase of the tuxstor project.

> 2. The aggregation lports are per filer, not per virtual server.
> 
> 3. The normal practice is to send all packets belonging to a single
> connection via a single link and not do a round-robin schedule for
> the individual packets. We need to make sure the right aggregation
> algorithm is selected. 

Removed as it was not in the scope of the vsvr design.

> 4. Which setsockopt()/getsockopt() call is that? How are packets from
> the service VM going to be forwarded through the virtual server
> interfaces? They can't call setsockopt(). What is the kernel
> interface for the same? Doing setsockopt() and then sending a packet
> will not work because kernel is multithreaded. Setsockopt() will not
> work for multithreaded user space code either.

There are no VMs in phase one of this project.

Not sure what you mean about s/getsockopt won't work for
multi-threaded code.  s/getsockopt has nothing to do with
multithreadedness.  Can you be more forthcoming?  Because the way you
worded this it sounds like you are trying to say setsockopt doesn't
work, ever, for anything, because the kernel is multithreaded.  Which
is obviously quite silly.

> 5. Currently there are separate listening sockets per virtual server
> on txrx. Is this going to be changed?  

Currently there aren't sockets on txrx at all.

> 6. If this is going to be changed, there needs to be some code to
> find out correct virtual server when a new connection is created or a
> packet is received on listening udp socket.

Congratulations, you have now been promoted to Captain Obvious.

> 7. Why do we need to reduce the reference count dependencies?
> Reference counts are there so you can depend on them.

Duh, why copy pointers and therefore have to do reference counts when
you can just copy an integer around instead?

> 8. In the current code the networking can be reconfigured without
> disabling a virtual server, are there going to be any limitations
> regarding that? The supporting code has to deal with terminating the
> connections that have been established to the deleted ip addresses.

Yes.

> 9. Is the code to terminate all virtual server connections when the
> virtual server is disabled part of these changes?

Anything is possible.  Something wrong with the old code?

> 10. interface enable/disable - this does not enable or disable the
> physical link, this disables the virtual server ability to
> send/receive packets using the ip addresses assigned to the interface
> and closes all the connections established on these addresses.

This disables the interface, which isn't a physical interface, but it's
an interface nonetheless.  No special code is needed on the front side
to terminate connections that are on an interface that is brought down,
the kernel should handle that as it normally does.

> Max
> 
> -----Original Message-----
> From: Rendell Fong [mailto:Rendell.Fong@lsi.com] 
> Sent: Monday, October 19, 2009 10:35 AM
> To: Sharp, Andy; Stark, Brian; Kozlovsky, Maxim; Fisher, Bill;
> Ariyamannil, Jobi Cc: Vandever, Chris
> Subject: description of virtual server changes
> 
> Enclosed is a description of the virtual server changes (as I see it
> so far) for TuxStor.
> 
