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 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?

Thanks,
ferruh