Hi Akhil, > Hi Konstantin, > > > > Hardware IP reassembly may be incomplete for multiple reasons like > > > > reassembly timeout reached, duplicate fragments, etc. > > > > To save application cycles to process these packets again, a new > > > > mbuf ol_flag (RTE_MBUF_F_RX_IPREASSEMBLY_INCOMPLETE) is added to > > > > show that the mbuf received is not reassembled properly. > > > > > > If we use dynfiled for data, why not use dynflag for > > > RTE_MBUF_F_RX_IPREASSEMBLY_INCOMPLETE? > > > That way we can avoid introduced hardcoded (always defined) flags for that > > > case. > > > > I have not looked into using dynflag. Will explore if it can be used. > The intent of adding this feature is to reduce application cycles for IP > reassembly. > But if we use dynflag, it will take a lot of cycles to check if dyn flag is > set or not. > As I understand, it first need to be looked up in a linked list and then > checked. > And this will be checked for each packet even if there is no reassembly > involved.
No, I don't think it is correct understanding. For dyn-flag it is the same approach as for dyn-field. At init time it selects the bit which will be used and return it'e value to the user. Then user will set/check the at runtime. So no linking list walks at runtime. All you missing comparing to hard-coded values: complier optimizations.
