Re: [dpdk-dev] [PATCH v2 3/3] net/af_packet: get 'framesz' from the iface's MTU

["Yigit, Ferruh" <ferruh.yigit@linux.intel.com>]

On 2/18/2019 6:01 PM, Yigit, Ferruh wrote:
> On 11/28/2018 1:12 PM, Lam, Tiago wrote:
>> On 27/11/2018 17:43, Ferruh Yigit wrote:
>>> On 11/20/2018 10:26 AM, Tiago Lam wrote:
>>>> Use the underlying MTU to calculate the framsize to be used for the mmap
>>>> RINGs. This is to make it more flexible on deployments with different
>>>> MTU requirements, instead of using a pre-defined value of 2048B.
>>>
>>> This behavior change should be documented in af_packet documentation which is
>>> missing unfortunately.
>>> Would you able to introduce the initial/basic af_packet doc to at least to
>>> document device argument? If not please let me know, I can work on it.
>>>
>>
>> Thanks for the review, Ferruh.
>>
>> Yeah, I don't mind cooking something up and submitting here for review;
>> I'll wait a couple of days for a reply from John W. before proceeding,
>> though.
>>
>> But given there's no documentation for af_packet yet, do you prefer to
>> wait for that to be available, and apply it all together? Or could that
>> be applied later as part of another patch?
> 
> Unfortunately Tiago was not able to work on this task anymore.
> And since Tiago's af_packet doc update already merged, I was planning to
> complete the task and applied the comments into his patchset but had a few
> questions, sharing here in case there are more interested people on task, cc'ed
> Ian & Kevin.
> 
> Code is not functioning correct when there are gaps in the block, I mean when
> block size is not multiple of frame size. There can be some assumption in the
> code that memory is continuous.
> 
> Also I am not sure the benefit of the using MTU for this case. There are a few
> restrictions, block size should be multiple of page size, it is 4K by default.
> When using MTU, 1500, for frame size, instead of 2048 Bytes hardcoded value,
> still only 2 frames fit into blocksize and there is no benefit, (and it is not
> functioning with current code as I mentioned above.)
> So this can be required for the cases MTU is bigger than 2048, not sure if this
> is the concern of the patch.
> Also it can provide some memory optimization when MTU is 1024 bytes or less, so
> this provides memory optimization more than flexibility on deployment.
> 
> Hi Ian, Kevin,
> 
> Are you aware of any use case of this patch in OvS?

It seems there is no follow up to this patchset, I am updating them as not
applicable.

For references, patches mentioned are:
https://patches.dpdk.org/user/todo/dpdk/?series=2498