Many thanks for the sharing. Yes, as you pointed out, it might not worthwhile to do offload for vlan.
Regards, Kingwel From: Damjan Marion <dmar...@me.com> Sent: Monday, January 07, 2019 9:18 PM To: Kingwel Xie <kingwel....@ericsson.com> Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] ethernet-input on master branch On 7 Jan 2019, at 12:38, Kingwel Xie <kingwel....@ericsson.com<mailto:kingwel....@ericsson.com>> wrote: thanks, Damjan, that is very clear. I checked the device-input and ethernet-input code, and yes I totally understand your point. Two more questions, I can see you spend some time on avf plugin, do you think it will eventually become the main stream and replace the dpdk drivers some day? I don't think we want to be in device driver business, unless device vendors pick it up, but on other side it is good to have one native implementation and AVF is good candidate due to compatibility with future Intel cards and quite simply communication channel with PF driver. DPDK is suboptimal for our use case, and with native implementation it is easy to show that... For vlan tagging, would you like to consider using the HW rx and tx offload to optimize the vlan sub-interface? Question here is: is it really cheaper to parse dpdk rte_mbuf metadata to extract vlan or to simply parse ethernet header as we need to parse ethernet header anyway. Currently code is optimised for untagged, but we simply store u64 of data which follows ethertype. It is just one load + store per packet but allows us to optionally do vlan processing if we detect dot1q or dot1ad frame. On the tx side, it is also questionable specially for L3 path, as we need to apply rewrite string anyway, so only difference is do we memcpy 14, 18 or 22 bytes... -- Damjan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11860): https://lists.fd.io/g/vpp-dev/message/11860 Mute This Topic: https://lists.fd.io/mt/28940805/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
