Acrypto API

[David McCullough]

Jivin Herbert Xu lays it down ...
> David McCullough <davidm at snapgear.com> wrote:
> > 
> > Are their other examples of this already floating around
> > in the kernel source that you know of ?  Especially from
> > a load balancing point of view ?
> 
> Yes.  This is how we do load balancing for network devices.  Whether it
> be eql, teql, or Ethernet bonding, they all present a standard network
> device interface.

There you go,  I have used it but never looked at how it was implemented.

> I think Evganiy might have misunderstood me slightly.  Even though they
> all present the same interface to their users, they can use completely
> different implementations underneath.
> 
> For example, eql talks to its slave devices directly through the network
> device API.  While teql talks to its slaves through the qdisc mechanism.
> 
> So using the same API for load balancers and crypto drivers do not place
> any restrictions on how they're implemented.  We're only asking for them
> to present a unified interface to the user.

If it is working well for eql/teql etc,  then that sets a precedent.

The network ideas sound a little like Evganiy's crypto routes.

If you think of the HW as a network devices and the algs as destinations
that can be reached through an interface via routes then I can see it
fitting a similar structure to networking.

> > As Evganiy has pointed out,  the API needs to be able to assist
> > with load balancing.  So no matter where you do it,  the information
> > needed is the same.  I guess it depends on how much it complicates the
> > drivers.
> 
> Agreed.
> 
> The differences as I see it is less infrastructure and more flexibility.
> Treating load balancers differently from the crypto devices means that
> you won't be able to nest them.  Even though 99% of the users probably
> won't do such a thing (but then 99% of them will only have one device
> as you noted below), if we can allow for that possibility without
> burdening ourselves too much, then why not.

Most systems will need a SW implementaion, whether that is one or many
drivers is another topic.

The next would be the addition of a HW device.

I would be confident that would cover 99% of systems easily.  Devices
with multiple crypto devices are hardly common place,  though it should
be easy to scale it as you never know ;-)

> > I figure you need some way to determine the "expected" throughput for a real
> > driver so that you can proportion the load,  and you also need a flow
> > control mechanism to determine when a driver is too busy to take more
> > requests for whatever reason.  Both relatively simple on their own :-)
> 
> Yes this is the sort of thing we need to pin down: what constitutes a
> crypto device driver API.
> 
> On the specific issue of device speed, I believe that it is best to
> do as much as we can at run-time.  For instance, the load balancers
> could conceivable test-run the slave devices to get a basic idea of
> their relative speeds.

I agree with that idea,  having the balancer rate the engines can save a
lot of configuration pain.  Just because you are using XYZ HW driver
doesn't take into account bus speeds/widths and so on.

I can vouch that a HIFN chip in a 66MHz 64Bit configuration leaves
a 32-bit/33MHz device in it's dust,  exactly the same driver code
running on both.  There can be a lot of variables.

Perhaps the option to manually override it in some way for the hard
core tuners who know what they are doing ?

> > All in all,  I think it's probably best kept at the top layer or
> > somewhere that the drivers and their capabilities are being registered
> > and managed.  Something that is reflected in both Evganiy's solution and
> > the OCF one I guess,
> 
> Oh yes whichever way we go there needs to be some infrastructure there
> to manage all the entities.  My view is that we should keep that as
> simple as possible since everybody will have to live with them.
> 
> If we treat everything as a crypto device, then all we need is a method
> of communicating with a specific crypto device through the API, and a
> global default device which is what most users will talk to.

As I see it,  here is the only thing that concerns me with this approach.

What I like at the moment,  with OCF and AFAICT Evganiy's acrypto, it is
very easy to write a driver that does one thing.  For example,  I can
write a driver that just does big num stuff for public key work on some
specialist HW just for this purpose (driver A).  I can write another for a
more general purpose chip that does DES/AES/...,  and just that (driver
B).  The driver registers itself,  with its capabilities and the framework then
dispatches the requests to a driver capable of processing the request.

Now,  if I understand what you are proposing correctly,  you have
something like these possibilities.

Only load driver A,  the only crypto that works is the big num stuff,
everything else fails as the driver doesn't support it.

I then write a dispatcher driver,  same API, but it handles making the
requests to a driver below it that can handle the actual request.
It can learn this at load time by exercising interfaces or some other
mechanism.

Now I want  load balancing,  do you add this to the simple dispatcher
driver or write another driver that does load balancing?  Then how to
layer this.  Does the load balancer go above/below or beside the dispatcher ?
My guess is that it probably makes sense for load balancing to be part of
the dispatcher since they are very similar tasks.

It seems to be tending towards always having 2 or maybe 3 layers,  the
management layer, the balancing/dispatching layer and the real crypto
provider layer.  I can't think if any other layers at the moment,  unless you
start doing distributed crypto processing or something ;-)

For networking I can understand how well this works.  For example I
could be load balancing PPPoE,  which is PPP running on top an ethernet
interface,  or just load balancing an ethernet connection with some
other network device.  We can load balance traffic across anything that
presents a network interface.  Nice :-)

Imagine you want to load balance two network interfaces,  only one of
them only handles tcp traffic on port 80,  everything else fails.
I am fairly sure you can configure teql and friends to only load
balance port 80 traffic over the two interfaces,  but this would be a
choice based on traffic type,  not on the capabilities of the underlying
HW.   Most people will not understand that driver A can only do PK
because that is all the HW supports.

Anyway,  this is long enough already.  Do the scenarios make sense
to you ?  Do you see a problem at all ?

Cheers,
Davidm

PS.
	I am having trouble with your email address (bounced messages without
	a real reason), just in case it something you need to know about :-)
	Let me know if you want a copy.

-- 
David McCullough, davidm at snapgear.com  Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security   Fx:+61 7 38913630 http://www.uCdot.org