The i350 should support timestamping all packets as I recall. You should probably look into getting the linuxptp package and seeing if you can make use of the hwstamp_ctl command to enable timestamping for all incoming packets on the adapter.
- Alex On 10/08/2015 12:33 AM, Mattias Barthel wrote: > 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 <mailto: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
