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.
--
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
