On Sat, Jan 8, 2011 at 11:09 AM, Hamid Nassiby <h.nassiby@xxxxxxxxx> wrote:
>
> On Fri, Dec 31, 2010 at 12:49 AM, Herbert Xu
> <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > Hamid Nassiby <h.nassiby@xxxxxxxxx> wrote:
> > > Hi,
> > >
> > > As some good news and additional information, with the following patch
> > > I no more get
> > > "UDP bad cheksum" error as I mentioned erlier with Iperf in udp mode.
> > > But some times I get the following call trace in dmesg after running
> > > Iperf in UDP mode, more than one time (and ofcourse Iperf stops
> > > transferring data while it uses 100% of CPU cycles.
> > >
> > >
> > >
> > > [ Â130.171909] mydriver-aes: mydriver Crypto-Engine enabled.
> > > [ Â134.767846] NET: Registered protocol family 15
> > > [ Â200.031846] iperf: page allocation failure. order:0, mode:0x20
> > > [ Â200.031850] Pid: 10935, comm: iperf Tainted: P Â Â Â Â Â Â2.6.36-zen1 #1
> > > [ Â200.031852] Call Trace:
> > > [ Â200.031860] Â[<ffffffff8108ab39>] ? __alloc_pages_nodemask+0x6d3/0x722
> > > [ Â200.031864] Â[<ffffffff810b454f>] ? virt_to_head_page+0x9/0x30
> > > [ Â200.031867] Â[<ffffffff810afac2>] ? alloc_pages_current+0xa5/0xce
> > > [ Â200.031869] Â[<ffffffff810899ad>] ? __get_free_pages+0x9/0x46
> > > [ Â200.031872] Â[<ffffffff8102bbbf>] ? need_resched+0x1a/0x23
> > > [ Â200.031876] Â[<ffffffff811a10ad>] ? blkcipher_walk_next+0x68/0x2d9
> >
> > This means that your box has run out of memory temporarily.
> > If all errors were handled correctly it should continue at this
> > point.
> >
> > > --- mydriver1 Â 2010-12-21 15:20:17.000000000 +0330
> > > +++ mydriver2 Â 2010-12-21 15:24:18.000000000 +0330
> > > @@ -1,4 +1,3 @@
> > > -
> > > static int
> > > mydriver_cbc_decrypt(struct blkcipher_desc *desc,
> > > Â Â Â Â Â Â Â Â Âstruct scatterlist *dst, struct scatterlist *src,
> > > @@ -14,18 +13,17 @@ mydriver_cbc_decrypt(struct blkcipher_desc
> > > Â Â Â Âerr = blkcipher_walk_virt(desc, &walk);
> > > Â Â Â Âop->iv = walk.iv;
> > >
> > > - Â Â Â while((nbytes = walk.nbytes)) {
> > > +
> >
> > However, your patch removes the error checking (and the loop
> > condition) which is why it crashes.
> >
> > Cheers,
> > --
> > Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> > Home Page: http://gondor.apana.org.au/~herbert/
> > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
>
>
> Hi Herbert,
>
> First I should notice that by removing while loop iteration, "UDP bad checksum"
> error in dmesg output is no longer seen. Diving deeper in problem, It seemed
> to me that when mydriver_transform returns 0, I must not get any more bytes
> (belonging to previous request) to process in the next iteration of while loop.
> But I see that the behavior is not as it has to be (By removing while loop
> mydriver_transform gets for example one 1500 byte request, processes it and
> copies it back to destination, But in existence of while loop It gets same
> request as one 1300 byte request, processes and copies it back to destination,
> returning 0, and getting remaining 200 bytes of request in second iteration of
> while, so on the other end of tunnel I see "UDP bad checksum"). So I conclude
> that blkcipher_walk_done behaves strange, assigns incorrect value to walk.nbytes
> resulting in iterating while loop one time more!
>
>
> Second note is about our accelerator's architecture and the way we should
> utilize it. Our device has several crypto engines built in. So for maximum
> utilization of device we should feed it with multiple crypto requests
> simultaneously (I intended for doing Âit by using pcrypt) and here is the point
> everything freezes. From other point of view, I found that if I protect entering
> write_request and read_response in mydriver_transform by one lock
> (spin_unlock(x) before write_request and spin_unlock(x) after read_reasponse in
> mydriver_transform as shown in following code snippet), I would be able to run
> "iperf" in tcp mode successfully. This leads me to uncertainty, because in
> such a situation, we only utilize one crypto engine of device and each request
> is followed by its response sequentially and arrangement of requests and
> responses is not interleaved. So I guess that getting multiple requests to
> device and receiving the responses not in the same arrangement they delivered to
> device, might cause TCP transfer to freeze, and here my question arises: If my
> conclusion is true, SHOULD I change the driver approach to ablkcipher?
>
>
> Code snippet in the way write_request and read_response are protected by lock
> and iperf in TCP mode progresses:
>
>
> static inline int mydriver_transform(struct mydriver_aes_op *op, int alg)
> {
> Â Â Â Â Â Â Â Â.
> Â Â Â Â Â Â Â Â.
> Â Â Â Â Â Â Â Â.
> Â Â Â Â Â Â Â Âspin_lock_irqsave(&glock, tflag);
> Â Â Â Â Â Â Â Âwrite_request(req_buf, req_len);
> Â Â Â Â Â Â Â Âkfree(req_buf);
> Â Â Â Â Â Â Â Âreq_buf = NULL;
> Â Â Â Â Â Â Â Âerr = read_response(&res_buf,my_req_id);
> Â Â Â Â Â Â Â Âspin_unlock_irqrestore(&glock, tflag2);
> Â Â Â Â Â Â Â Âif (err == 0){
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âkfree(res_buf);
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âres_buf = NULL;
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âreturn 0;
> Â Â Â Â Â Â Â Â}
>
> Â Â Â Â Â Â Â Âmemcpy(op->dst, (res_buf + sizeof(struct response_hdr)),
> op->len);
>
> Â Â Â Â Â Â Â Âkfree(res_buf);
> Â Â Â Â Â Â Â Âres_buf = NULL;
> Â Â Â Â Â Â Â Âreturn op->len;
> }
>
>
> I'm looking forward to hearing you soon.
> Thanks,
>
> Hamid.
Hi,
As you know, I posted my problem again to crypto list and no one answered. Now I
emphasize one aspect of the problem as a concept related to IPSec protocol, free
of my problem's nature, and I hope to get some guidelines at this time. The
question is as following:
If IPSec delivers IP packets to hardware crypto accelerator in sequential manner
(e.g, packets in order: 1, 2, 3, ..., 36, 37, 38,...) and crypto accelerator
possibly returns back packets out of entering order to IPSec (e.g, packet
37 is returned back before the packet 36 to IPSec, so the order of packets is
not the same before entering crypto accelerator and after exiting it); Is it
possible to rise any problem here?
Thanks in advance,
Hamid.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
