Hi thanks for answer. Unfortunately, the udp/ip stream just as the cfm stream is against only one peer. Furthemore on the guest side I have only one vcpu tied to two physical siblings to minimize L2 cache misses on ISRs due to cache coherence.
I had an idea this morning, maybe I can make use of the ptp hw timestaming for this? This should give better accuracy. Is this possible or does it only work for ethertype ptp? On Thursday, October 8, 2015, Alexander Duyck <alexander.du...@gmail.com> wrote: > 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 <javascript:;>> > > 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 <javascript:;> > https://lists.sourceforge.net/lists/listinfo/e1000-devel > To learn more about Intel® Ethernet, visit > http://communities.intel.com/community/wired > -- Avis de confidentialité Les informations contenues dans le présent message et dans toute pièce qui lui est jointe sont confidentielles et peuvent être protégées par le secret professionnel. Ces informations sont à l’usage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s’il vous plait communiquer immédiatement avec l’expéditeur et en détruire tout exemplaire. De plus, il vous est strictement interdit de le divulguer, de le distribuer ou de le reproduire sans l’autorisation de l’expéditeur. Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential information which may be privileged and which is intended for the exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or copying of this message and/or any attachment hereto without the consent of the sender is strictly prohibited. Thank you.
------------------------------------------------------------------------------
_______________________________________________ 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
