Hi, Andrew > >> At least there are few simple limitations which are easy to > >> express: > >> 1. Maximum number of segments > > We have scatter capability and we do not report the maximal number of > > segments, it is on PMD own. We could add the field to the > > rte_eth_dev_info, but not sure whether we have something special to report > there even for mlx5 case. > > There is always a limitation in programming and HW. Nothing is unlimited. > Limits could be high, but still exist. > Number of descriptors? Width of field in HW interface? > Maximum length of the config message to HW? > All above could limit it directly or indirectly.
None of above is applicable to mlx5 buffer split feature - it just adjusts the Rx buffer pointers and segment sizes, no anything beyond generic limitation - the queue descriptor numbers and mbuf buffer size. Suppose the most of HW by other vendors is capable to support buffer split feature with similar generic limitations. > > >> 2. Possibility to use the last segment many times if required > >> (I was suggesting to use scatter for it, but you rejected > >> the idea - may be time to reconsider :) ) > > > > Mmm, sorry I do not follow, it might be I did not understand/missed your > idea. > > Some of the last segment attributes are used multiple times to scatter > > the rest of the data in fashion very close to the existing scattering > > approach - at least, pool and buffer size from this pool are used. The > > beginning of the packet scattered according to the new descriptions, > > the rest of the packet - according to the existing regular scattering > > with pool settings from the last segment description. > > I believe that the possibility to split into a fixed segments > (BUFFER_SPLIT) and possibility to use a mempool (just mp or last segment) > many times if a packet does not fit (SCATTER) it is *different* features. Sorry, what do you mean "use mempool many times"? Allocate multiple mbufs from the same mempool and build the chain of them? We have SCATTER offload and many PMDs advertise that. Scattering is actually the split, the split happens on some well-defined points to the mbufs from the same pool. BUFFER_SPLIT just extends SCATTER capabilities by providing the split point arbitrary settings and multiple pools. > I can easily imagine HW which could do BUFFER_SPLIT to fixed segments, but > cannot use the last segment many times (i.e. no classical SCATTER). Sorry, what do you mean "BUFFER_SPLIT to fixed segments" ? This new offload BUFFER_SPLIT is intended to push data to flexible segments, potentially allocated from the different pools. The HW can be constrained with pool number (say it supports some pool alloc/free hardware accelerator for single pool only), in this case it will not be able to support BUFFER_SPLIT in multiple pool config, but using the single pool does not arise the problem. It seems I missed something, could you, please, provide an example, how would you like to see the usage last segment many times for BUFFER_SPLIT? How the packet should be split, in mbufs with what (last segment inherited) attributes? > > > > > 3. Maximum offset > >> Frankly speaking I'm not sure why it cannot be handled on > >> PMD level (i.e. provide descriptors with offset taken into > >> account or guarantee that HW mempool objects initialized > >> correctly with required headroom). May be in some corner > >> cases when the same HW mempool is shared by various > >> segments with different offset requirements. > > > > HW offsets are beyond the feature scope, the offsets in the segment > > description is supposed to be added to the native pool offsets (if any). > > Are you saying that offsets are not passed to HW and just handled by PMD to > provide correct IOVA addresses to put data to? If so, it is an implementation > detail which is specific to mlx5. If so, no specific limitations except data > room, > size and offset consistency. > But it could be passed to a HW and it could be, for example, just 8 bits for > the > value. Yes, it could. But there should be other vendors be involved, not known for now who is going to support BUFFER_SPLIT and in which way. We should not invent some theoretical limitations and merge the dead code. And, please note - Tx segmentation has been living for 10 years successfully without any limitations, no one cares about, there is no any request to report. Likewise is expected for Rx. > > > > >> 4. Offset alignment > >> 5. Maximum/minimum length of a segment 6. Length alignment > > In which form? Mask of lsbs ? 0 means no limitations ? > > log2, i.e. 0 => 1 (no limitations) 1 => 2 (even only), > 6 => 64 (64-byte cache line aligned) etc. > Yes, possible option. > > > >> > >> I realize that 3, 4 and 5 could be per segment number. > >> If it is really that complex, report common denominator which is > >> guaranteed to work. If we have no checks on ethdev layer, application > >> can ignore it if it knows better > > > > Currently it is not clear at all what kind of limitations should be > > reported, we could include all of mentioned/proposed ones, and no one > > will report there - > > mlx5 has no any reasonable limitations to report for now. > > > > Should we reserve some pointer field in the rte_eth_dev_info to report > > the limitations? (Limitation description should contain variable size > > array, depending on the number of segments, so pointer seems to be > appropriate). > > It would allow us to avoid ABI break, and present the limitation structure > once it is defined. > > I will let other ethdev maintainers to make a decision here. > My vote would be to report limitations mentioned above. > It looks like Jerin is also interested in limitations reporting. Not sure if > my form > looks OK or no. For now I tend to think we could reserve some pointer for BUFFER_SPLIT limitations and that's it. Reporting some silly generic limitations from mlx5 means introducing the dead code in my opinion. If we'll see the actual request from applications to check and handle limitations (actually applications are very limited in this matter - they expect the split point to be set at very strong defined place of the packet format).
