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
