Hi Mattias, First of all there is no real firmware that runs on these e1000 support devices. So I want to make that clear that there isn't something running behind the scenes. If you really turned off the interrupt delay and NAPI is off the issue is most likely because of the write-back threshold. I you just wait for it the packet seems to show up (your printk and udelay cases). So when do you start looking for the that last packet? What are you using to look for that packet?
Cheers, John > -----Original Message----- > From: Mattias Barthel [mailto:mbart...@accedian.com] > Sent: Thursday, February 18, 2016 11:24 AM > To: e1000-devel@lists.sourceforge.net > Subject: [E1000-devel] e1000 i82573 rotting packet? > > Hello, > > Im investigating a possible race between FW and SW ISR. > > Model: > e1000: chipset i82573 > versions: > > driver: e1000 > version: 7.3.20-k2pt > firmware-version: 0.5-7 > > I am seeing rx delays up to 4ms when receiving bursts of around 3-4-5 > packets very tightly almost back-to-back. The time distance between bursts > is, just that, around 4ms. It seems that the rotting packet occurs, namely > that > the last packet(s) in a burst is not consumed until next burst. > > I have turned off ITR and RxDelay. > I have disabled NAPI. > This to instantly honour incoming packets. > > e1000_intr: > > static irqreturn_t > e1000_intr(int irq, void *data) > { > struct net_device *netdev = data; struct e1000_adapter *adapter = > netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; uint32_t icr = > E1000_READ_REG(hw, ICR); > > if (unlikely(!icr)) > return IRQ_NONE; /* Not our interrupt */ > > > if (unlikely(icr & E1000_ICR_LSC)) { > > hw->get_link_status = 1; > > /* > * guard against interrupt when we're going down > */ > > if (!test_bit(__E1000_DOWN, &adapter->flags)) > mod_timer(&adapter->watchdog_timer, jiffies + 1); } > > adapter->clean_rx(adapter, adapter->rx_ring); > > e1000_clean_tx_irq(adapter, adapter->tx_ring); > > return IRQ_HANDLED; > } > > > e1000_clean_rx_irq: > > e1000_clean_rx_irq(struct e1000_adapter *adapter, > struct e1000_rx_ring *rx_ring) { struct net_device *netdev > = > adapter->netdev; > struct pci_dev *pdev = adapter->pdev; > struct e1000_rx_desc *rx_desc, *next_rxd; > struct e1000_buffer *buffer_info, *next_buffer; > //unsigned long flags; > uint32_t length; > uint8_t last_byte; > unsigned int i; > int cleaned_count = 0; > boolean_t cleaned = FALSE; > unsigned int total_rx_bytes=0, total_rx_packets=0; > struct timeval rxtv, rxtv_res; > static struct timeval last_rxtv = {0, 0}; uint32_t icr; > int count_rotting = 0; > struct e1000_hw *hw = &adapter->hw; > > again: > i = rx_ring->next_to_clean; > rx_desc = E1000_RX_DESC(*rx_ring, i); > buffer_info = &rx_ring->buffer_info[i]; > > timestamp(&rxtv); > > > while (rx_desc->status & E1000_RXD_STAT_DD) { > .............snip.consume > and unmap DMA:ed buffers....... > } > > rx_ring->next_to_clean = i; > > cleaned_count = E1000_DESC_UNUSED(rx_ring); if (cleaned_count) > adapter->alloc_rx_buf(adapter, rx_ring, cleaned_count); > > adapter->total_rx_packets += total_rx_packets; > adapter->total_rx_bytes += total_rx_bytes; > > adapter->net_stats.rx_packets += total_rx_packets; > adapter->net_stats.rx_bytes += total_rx_bytes; > > ......after tis line I added code to try and remedy the problem..... > timersub(&rxtv, &last_rxtv, &rxtv_res); last_rxtv = rxtv; > > if (rxtv_res.tv_usec > 1500) { > udelay(10); > // printk("new burst: cleaned: %d, timestamp: %d.%06d\n", > cleaned_count, (int)rxtv.tv_\ > sec, (int)rxtv.tv_usec); > } > > icr = E1000_READ_REG(hw, ICR); > if ((icr) && count_rotting++ < 10) { > total_rx_bytes = 0; > total_rx_packets = 0; > > // printk("more to read in rx_ring: rotting :%d, > cleaned: %d, timestamp: %d.%0\ > 6d\n", count_rotting, cleaned_count, (int)rxtv.tv_sec, (int)rxtv.tv_usec); > > cleaned_count = 0; > goto again; > } > > return cleaned; > } > > So, with the udelay or with the printk to dmesg the problem (almost) goes > away. > > What is happening here? > > Thanks in advance. > > Mattias > > -- > > > 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. ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ 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
