<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2>
<DIV><FONT face=Arial size=2><SPAN class=408381517-04122006>Hi
All</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=408381517-04122006>I am trying to get
the USE_BATCH (=1) mode to work for my crypto driver. I guess I have
found some problem, that is, crypto driver signals ERESTART as a function call
return (line 1317 below), then the crypto thread sets the cc_qblocked to 1
(line 1333 below).</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=408381517-04122006></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=408381517-04122006>
1</SPAN>303
if (submit != NULL) {<BR>
1304
/* AK added */<BR>
1305
//if (!( gKeepTrackOfCryptoThread % 100)) {<BR>
1306
// printk("6," );<BR>
1307
//}<BR>
1308
list_del(&submit->crp_list);<BR>
1309
CRYPTO_Q_UNLOCK();<BR> 1310<BR>
1311
//trace_set_L1(c,30); /* 30 is the id for OCF code */<BR>
1312
//trace_set_L1(f,7); /* trace point */<BR>
1313
//trace_log_L1(trace_var(c), trace_var(f), 200); /* log */<BR>
1314<BR>
1315
result = crypto_invoke(submit, hint);<BR>
1316
CRYPTO_Q_LOCK();<BR>
1317
if (result == ERESTART) {<BR> 1318<BR>
1319
/* AK added */<BR>
1320
//if (!( gKeepTrackOfCryptoThread % 100)) {<BR>
1321
// printk("7," );<BR>
1322
//}<BR>
1323
/*<BR>
1324
* The driver ran out of resources, mark the<BR>
1325
* driver ``blocked'' for cryptop's and put<BR>
1326
* the request back in the queue. It would<BR>
1327
* best to put the request back where we got<BR>
1328
* it but that's hard so for now we put it<BR>
1329
* at the front. This should be ok; putting<BR>
1330
* it at the end does not work.<BR>
1331
*/<BR>
1332
/* XXX validate sid again? */<BR>
1333
crypto_drivers[CRYPTO_SESID2HID(submit->crp_sid)].cc_qblocked =
1 ;<BR>
1334
list_add(&submit->crp_list, &crp_q);<BR>
1335
cryptostats.cs_blocks++;<BR>
1336
}<BR>
1337
}<BR></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT size=+0><SPAN class=408381517-04122006><FONT face=Arial
size=2>Because the crypto hardware is not able to cope up with the request now
it makes sense for the crypto thread to go to sleep and later be awakened by the
crypto driver. But I guess this thread doesn't go to sleep because the
wait_on_event condition argument is not turning out to be false. Here is the
code segment. Line 1414 should put the thread to sleep but it does not because
the submit queue is not empty, when crypto driver returned ERESTART.
</FONT></SPAN></FONT></DIV>
<DIV><FONT size=+0><SPAN class=408381517-04122006><FONT face=Arial
size=2></FONT></SPAN></FONT> </DIV>
<DIV><FONT size=+0><SPAN class=408381517-04122006><FONT face=Arial size=2>
1375
if (submit == NULL && krp == NULL) {<BR>
1376
/* AK added */<BR>
1377
//if (!( gKeepTrackOfCryptoThread % 100)) {<BR>
1378
// printk("8," );<BR>
1379
//}<BR>
1380
/*<BR>
1381
* Nothing more to be processed. Sleep until we're<BR>
1382
* woken because there are more ops to process.<BR>
1383
* This happens either by submission or by a driver<BR>
1384
* becoming unblocked and notifying us through<BR>
1385
* crypto_unblock. Note that when we wakeup we<BR>
1386
* start processing each queue again from the<BR>
1387
* front. It's not clear that it's important to<BR>
1388
* preserve this ordering since ops may finish<BR>
1389
* out of order if dispatched to different devices<BR>
1390
* and some become blocked while others do not.<BR>
1391
*/<BR>
1392
//printk("1 : sleeping \n");<BR>
1393
dprintk("%s - sleeping\n", __FUNCTION__);<BR>
1394
CRYPTO_Q_UNLOCK();<BR>
1395<BR> 1414
wait_event_interruptible(cryptoproc_wait,<BR>
1415
cryptoproc == (pid_t) -1 ||<BR>
1416
!list_empty(&crp_q) ||<BR>
1417
!list_empty(&crp_kq));<BR>
1418
...</FONT></SPAN></FONT></DIV>
<DIV><FONT size=+0><SPAN class=408381517-04122006><FONT face=Arial
size=2><BR></FONT></SPAN></FONT> </DIV>
<DIV><FONT size=+0><SPAN class=408381517-04122006><FONT face=Arial
size=2></FONT></SPAN></FONT> </DIV>
<DIV><FONT size=+0><SPAN class=408381517-04122006><FONT face=Arial size=2>From
the crypto driver routine I call crypto_unblock and believe the purpose of this
is to wake up the crypto thread. In the first place this thread didn't go to
sleep. Am I missing something? How this scheme is supposed to work? Didn't
anyone run into ERESTART condition and was able to get out this condition
gracefully? This ERESTART problem will show up more when the injected traffic to
the VPN testbed is very high. For instance, in the lab I was blasting 100%
of line rate (gigabit) with packet size of 1024B. </FONT></SPAN></FONT></DIV>
<DIV><FONT size=+0><SPAN class=408381517-04122006><FONT face=Arial
size=2></FONT></SPAN></FONT> </DIV>
<DIV><FONT size=+0><SPAN class=408381517-04122006><FONT face=Arial size=2>Please
shed some light.</FONT></SPAN></FONT></DIV>
<DIV><FONT size=+0><SPAN class=408381517-04122006><FONT face=Arial
size=2></FONT></SPAN></FONT> </DIV>
<DIV><FONT size=+0><SPAN class=408381517-04122006><FONT face=Arial size=2>Ahsan.
</DIV></FONT></SPAN></FONT></FONT></DIV></BODY></HTML>