Am Freitag, 13. Januar 2017, 19:25:39 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 12:16:27PM +0100, Stephan Müller wrote:
> > > If you're making a single call, what guarantees the ordering?
> >
> > Technically, io_submit is the syscall that triggers the recvmsg. Are you
> >
Am Freitag, 13. Januar 2017, 19:25:39 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 12:16:27PM +0100, Stephan Müller wrote:
> > > If you're making a single call, what guarantees the ordering?
> >
> > Technically, io_submit is the syscall that triggers the recvmsg. Are you
> >
On Fri, Jan 13, 2017 at 12:16:27PM +0100, Stephan Müller wrote:
>
> > If you're making a single call, what guarantees the ordering?
>
> Technically, io_submit is the syscall that triggers the recvmsg. Are you
> saying that this syscall does not maintain ordering? At least the man page
> does
Am Freitag, 13. Januar 2017, 19:12:59 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 12:10:02PM +0100, Stephan Müller wrote:
> > > Well if ordering is not guaranteed that I don't see how your code
> > > can work either. Or am I missing something?
> >
> > The patch simply stores
On Fri, Jan 13, 2017 at 12:10:02PM +0100, Stephan Müller wrote:
>
> > Well if ordering is not guaranteed that I don't see how your code
> > can work either. Or am I missing something?
>
> The patch simply stores all data it gets from sendmsg in the src SGL. In
> addition it maintains an offset
Am Freitag, 13. Januar 2017, 19:03:35 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 11:49:05AM +0100, Stephan Müller wrote:
> > According to the man page of lio_listio(3) the provided AIO operations are
> > executed in an unspecified order. I would infer from that statement that
On Fri, Jan 13, 2017 at 11:49:05AM +0100, Stephan Müller wrote:
>
> According to the man page of lio_listio(3) the provided AIO operations are
> executed in an unspecified order. I would infer from that statement that even
> if an order of write / read / write / read is defined by the caller,
Am Freitag, 13. Januar 2017, 18:21:45 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 05:19:57PM +0100, Stephan Müller wrote:
> > > I don't understand, what's wrong with:
> > >
> > > sendmsg(fd, ...)
> > > aio_read(iocb1)
> > > sendmsg(fd, ...)
> > > aio_read(iocb2)
> >
> > Sure,
On Thu, Jan 12, 2017 at 05:19:57PM +0100, Stephan Müller wrote:
>
> > I don't understand, what's wrong with:
> >
> > sendmsg(fd, ...)
> > aio_read(iocb1)
> > sendmsg(fd, ...)
> > aio_read(iocb2)
>
> Sure, that works. But here you limit yourself to one IOCB per aio_read. But
> aio_read supports
Am Freitag, 13. Januar 2017, 00:17:59 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 05:10:14PM +0100, Stephan Müller wrote:
> > Each IOCB would transpire into an independent, separate recvmsg invocation
> > without an additional sendmsg/sendpage operation. Thus, in order to
> >
On Thu, Jan 12, 2017 at 05:10:14PM +0100, Stephan Müller wrote:
>
> Each IOCB would transpire into an independent, separate recvmsg invocation
> without an additional sendmsg/sendpage operation. Thus, in order to support
> multiple IOCBs, all data the multiple recvmsg invocations will operate on
Am Freitag, 13. Januar 2017, 00:07:39 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 05:05:03PM +0100, Stephan Müller wrote:
> > Am Donnerstag, 12. Januar 2017, 16:56:04 CET schrieb Stephan Müller:
> >
> > Hi Herbert,
> >
> > > That would mean that we would only support one
Am Donnerstag, 12. Januar 2017, 16:56:04 CET schrieb Stephan Müller:
Hi Herbert,
>
> That would mean that we would only support one IOCB.
As we also need to be standards compliant, would it be appropriate to only
support one IOCB? I think this is a significant difference to other AIO
Am Donnerstag, 12. Januar 2017, 23:51:28 CET schrieb Herbert Xu:
Hi Herbert,
> On Sun, Dec 25, 2016 at 06:15:06PM +0100, Stephan Müller wrote:
> > + * The following concept of the memory management is used:
> > + *
> > + * The kernel maintains two SGLs, the TX SGL and the RX SGL. The TX SGL
> >
The updated memory management is described in the top part of the code.
As one benefit of the changed memory management, the AIO and synchronous
operation is now implemented in one common function. The AF_ALG
operation uses the async kernel crypto API interface for each cipher
operation. Thus, the
15 matches
Mail list logo
