> On 22 Mar 2019, at 09:35, Nitin Saxena <nsax...@marvell.com> wrote: > > Hi Damjan, > > >> Can we conclude that there is no technical arguments? > > On technical aspects: > Changing VLIB structure to 128 byte from current 256 byte (for our target) > In case of forwarding we only use single Dcache line till ipv4-input (because > of packet parsing info in second 64B of vlib). The second cache line, which > is data, being accessed only in ipv4-lookup and ipv4-rewrite node. With the > proposal we have to put our hardware parsing information to HEADROOM, thereby > increasing one cache line access to every node. This will impact performance > for us.
I don't think this is technical argument, it falls to me under tecnical depth category. Just for my curiosity, what’s wrong with putting your data into vlib_buffer_t-> opaque2 ? > Changing remaining per-thread structures to 128B > This proposal looks fine for other data structures. However: > i. You > already mentioned that in worst case there will be two prefetches of 64B but > in our processor second prefetch should be ignored. I checked internally and > yes the second prefetch will be ignored if the two prefetches are very close. > However the second prefetch will not be ignored on the very first instruction > pipeline. So I feel its wastage of few pipelining stages per packet. > Otherwise it looks fine to me. So here we just have your feeling, no real arguments, so i guess it is fine...
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12616): https://lists.fd.io/g/vpp-dev/message/12616 Mute This Topic: https://lists.fd.io/mt/30699557/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
