Driver questions

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Driver questions

Sean Hinde-2
> This is kind of what I thought from the docs but crypto seems
> to do it a
> little differently.. Here there is a server process which
> opens the driver,
> "owns" it, and puts the port reference in a 'protected' ets
> table (i.e. read
> allowed by all). The client functions read this table and call
> erlang:port_command in the context of the *calling* process.

Hmm, I just made a driver which does both mechanisms and the one which does
port_control in the calling process averages 20uS per call but the one which
uses driver_output averages about 35uS.

- Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.




Reply | Threaded
Open this post in threaded view
|

Driver questions

Raimo Niskanen-3
Sean Hinde wrote:

>
> > This is kind of what I thought from the docs but crypto seems
> > to do it a
> > little differently.. Here there is a server process which
> > opens the driver,
> > "owns" it, and puts the port reference in a 'protected' ets
> > table (i.e. read
> > allowed by all). The client functions read this table and call
> > erlang:port_command in the context of the *calling* process.
>
> Hmm, I just made a driver which does both mechanisms and the one which does
> port_control in the calling process averages 20uS per call but the one which
> uses driver_output averages about 35uS.
>

I would just like to mention that when a process calls port_command, the
->output code in the driver is executed, (perhaps) an answer is
generated and placed in the process's receive queue. Then port_command
returns and the process does a receive, which matches out the answer
from the receive queue. This implies more overhead than port_control,
which is just a BIF call that delivers the return value.

Also, port_command involves some more treatment of the buffer passed
down, to cope with the cases of the driver having an ->outpuv function,
etc. In this respect port_control is very starightforward.

And, port_control also have less overhead when returning data, at least
in the case when the data is less than 64 bytes (which you cannot rely
on).

The backdraws of port_command is that it is more limited, e.g no
vectorized output, cannot return binaries with list head
(driver_output2()), _cannot_ return an asynchronous reply, and certanly
more...

/ Raimo Niskanen, Ericsson UAB, Erlang/OTP