That’s a very good point. Looking at vnet_buffer, there seems to be some space
left in it for this case …
190 struct
191 {
192 /* input variables */
193 struct
194 {
195 u32 next_index; /* index of next node - used by custom
apps */
196 u32 error_next_index; /* index of next node if error -
used by custom apps */
197 };
198 /* handoff variables */
199 struct
200 {
201 u16 owner_thread_index;
202 };
203 };
we could put is_custom flag next to owner_thread_index; and if it is set then
the handoff code would send to ip4-full-reass-custom instead of ip4-full-reass.
We will need a fq_custom_index as well to be able to do that.
this would also be needed for ip6-full and ip4-sv flavours …
would you like to take this or should I write the code?
Thanks,
Klement
> On 8 Sep 2020, at 18:28, Satya Murthy <[email protected]> wrote:
>
> Thanks Klement for the quick response.
>
> I can make the changes you suggested. But, one major doubt I have is on the
> HANDOFF scenario.
>
> Let's say, as part of custom-reasm-node, if the packet is decided to be
> handed off to another thread, then the next_node is ALWAYS getting set as
> "ip4-full-reassembly-handoff".
> Shouldn't it go to custom-reasm-node ? This also needs to be decided based on
> "is_custom_app" , right ?
>
> Please let me know your inputs.
>
> --
> Thanks & Regards,
> Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17345): https://lists.fd.io/g/vpp-dev/message/17345
Mute This Topic: https://lists.fd.io/mt/76705450/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
