2 head = q->head;
for (i = tail; i < head; i++)
{
f = q->jobs[i & CRYPTO_SW_SCHEDULER_QUEUE_MASK];
[... do stuff ...]
}
It seems to me that these loops will not work correctly when
head wraps.
Thanks for your comments.
--
G. Paul Ziemba
FreeBSD unix:
}
> return (NULL);
>}
>[...]
>Commands coded like this work fine when typed one at a time, but they blow =
>chunks when scripted...
It seems possible that this incorrect pattern has propagated from
vpp/src/examples/sample-plugin/sample/sample.c
--
G. Paul Ziemba
FreeBSD unix:
art of
VPP? Requirements are the usual add/delete/search as well as fast
discovery of adjacent nodes (previous and next) after a search (skiplist
path afforded that).
thanks!
--
G. Paul Ziemba
FreeBSD unix:
12:51PM up 105 days, 20:32, 43 users, load averages: 0.32, 0.26, 0.41
-=-=-=-=-=-=-=-=-=-
>
> I dont have time to read that draft, but it looks to me that during
> decryption you can simply spray plaintext into multiple buffers, no?
The relevant aspect of the spec is that multiple payload packets may be
included in a single tunnel packet. These payload packets must be de-aggregated
>
> We do that by cloning, you can have multiple head buffers with small
> amount
> if data to accommodate l2/l3 headers and then such buffers have
> b->next_buffer
> pointing to shared tail buffer(s). Tail buffer(s) just need to have
> ref_count set properly
> to avoid that such buffer is freed p
ing in the packet output code to
handle this format. Is it correct that the VPP interface output
functions eventually call dpdk interface transmit functions? I'm
guessing that would be the place to do it.
Am I missing something? Is there a better way to approach this problem?
thanks!
--
G. Paul
Ah, thank you. That seems much more logical.
(Still familiarizing myself with tools in this toolbox. Haven't found the 10mm
socket yet.)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12620): https://lists.fd.io/g/vpp-dev/message/12620
Mute This T
.function and other fields but
unique .name fields (e.g., "name01", "name02", ..., "nameNN"): I think
this will set up distinct input frame queues for each such node.
Is there a better way to accomplish this N-queue pattern?
thanks!
--
G. Paul Ziemba
FreeBSD unix:
11:
