[Openswan dev] Openswan OCF : ----- USE_BATCH mode + ERESTART

[Kabir Ahsan-r9aahw]

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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/dev/attachments/20061204/fcd1645f/attachment.html