The difference could be Receive Side Scaling (RSS). The UDP/IP packets can be load balanced across all queues via RSS based on a hash of the source and destination addresses. So if you have multiple sources generating these packets, or they are being received on multiple IP addresses then it is possible the load is being spread out over multiple CPUs. Your CFM packets are on an Ethertype other than IPv4 or IPv6 so all packets will end up on queue 0 if I am not mistaken.
- Alex On 10/07/2015 10:21 PM, Mattias Barthel wrote: > Hi again! > > I realise my message might not have been so clear. > > I will try to clarify. I am doing PM with software timestamping. > > igb versions: > version: 3.0.6-k2 > firmware-version: 0.147-0 > > I do timestamping (NTP format) of the packets in the same place for all > protocols. (in igb_clean_rx_irq_adv()). > > For these non ip packets like IEEE 801.2ag CFM ETH-DM (ethertype 0x8902) I > get quite a lot worse accuracy in the timestamping. > > For UDP/IP TWAMP I get for 10k pps a max delay of around 140us back to back. > For CFM ETH DM I get for the same packet rate and packet size a max delay > of around 900us. > > So my hypothesis was: > Could FW be putting these L2 packets in another queue with different > characteristics? > > I tried to add a ET-type filter as written in my previous mail but it > showed no difference. > > > Thanks for any help given! > > > > On Mon, Oct 5, 2015 at 2:19 PM, Mattias Barthel <mattiasbart...@gmail.com> > wrote: > >> Greetings, >> >> Im getting quite bad latency when using the igb driver on i350 on linux >> regarding >> ETH CFM packets. This compared to TWAMP (IPv4 UDP packets). >> The environment is KVM with the i350 devices in PCI-passthrough. >> >> So i figured I add an own rx-queue (filter) for those types of ethernet >> protocol packets. >> >> This is what i added: >> >> >> wr32(E1000_ETQF(4), >> (1 << 31) | /* queue enable */ >> (E1000_ETQF_FILTER_ENABLE) | /* enable filter */ >> (1 << 29) | /* enable immediate interrupt */ >> (0x4 << 16) | /* queue no. 4 */ >> (ETH_P_8021AG)); /* 0x8902 CFM eth protocol type */ >> >> >> ETH_P_8021A is 0x8902 >> >> >> >> Is this a correct/good approach? >> >> Thanks in advance! >> >> -- >> Mattias Barthel >> > ------------------------------------------------------------------------------ _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
