Hi All
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).
1303 if (submit != NULL) {
1304 /* AK added */
1305 //if (!( gKeepTrackOfCryptoThread %
100)) {
1306 // printk("6," );
1307 //}
1308 list_del(&submit->crp_list);
1309 CRYPTO_Q_UNLOCK();
1310
1311 //trace_set_L1(c,30); /* 30 is the id
for OCF code */
1312 //trace_set_L1(f,7); /* trace point */
1313 //trace_log_L1(trace_var(c),
trace_var(f), 200); /* log */
1314
1315 result = crypto_invoke(submit, hint);
1316 CRYPTO_Q_LOCK();
1317 if (result == ERESTART) {
1318
1319 /* AK added */
1320 //if (!(
gKeepTrackOfCryptoThread % 100)) {
1321 // printk("7," );
1322 //}
1323 /*
1324 * The driver ran out of
resources, mark the
1325 * driver ``blocked'' for
cryptop's and put
1326 * the request back in the
queue. It would
1327 * best to put the request back
where we got
1328 * it but that's hard so for now
we put it
1329 * at the front. This should be
ok; putting
1330 * it at the end does not work.
1331 */
1332 /* XXX validate sid again? */
1333
crypto_drivers[CRYPTO_SESID2HID(submit->crp_sid)].cc_qblocked = 1
;
1334 list_add(&submit->crp_list,
&crp_q);
1335 cryptostats.cs_blocks++;
1336 }
1337 }
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.
1375 if (submit == NULL && krp == NULL) {
1376 /* AK added */
1377 //if (!( gKeepTrackOfCryptoThread %
100)) {
1378 // printk("8," );
1379 //}
1380 /*
1381 * Nothing more to be processed. Sleep
until we're
1382 * woken because there are more ops to
process.
1383 * This happens either by submission or
by a driver
1384 * becoming unblocked and notifying us
through
1385 * crypto_unblock. Note that when we
wakeup we
1386 * start processing each queue again
from the
1387 * front. It's not clear that it's
important to
1388 * preserve this ordering since ops may
finish
1389 * out of order if dispatched to
different devices
1390 * and some become blocked while others
do not.
1391 */
1392 //printk("1 : sleeping \n");
1393 dprintk("%s - sleeping\n",
__FUNCTION__);
1394 CRYPTO_Q_UNLOCK();
1395
1414
wait_event_interruptible(cryptoproc_wait,
1415 cryptoproc == (pid_t) -1
||
1416 !list_empty(&crp_q) ||
1417 !list_empty(&crp_kq));
1418 ...
>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.
Please shed some light.
Ahsan.