Sorry John, I dont think I answered your last question. Please see inline.
On Sat, Feb 20, 2016 at 12:36 AM, Mattias Barthel <mbart...@accedian.com>
wrote:
> Hi John, thanks for your answer.
>
> No real FW? FW can be different things in different situations, what I
> meant was
> programmable logic which is running on the HW of the NIC, not the driver
> running on the CPU(SW). It is probably an ASIC? Maybe MAC is a better word.
>
> The last packet is sometimes read when the next burst comes. It has been
> rotting since the last burst and therefore been delayed for 4ms. When
> delaying the ISR it occurs less often indicating a race condition?
> I am using a 1G connection with only a 1G switch between sender and
> receiver. The protocol used for measuring delays is TWAMP.
>
> Thanks for the tip on the write-back threshold. Would you care to explain
> how that works?
>
> Regards,
> Mattias
>
> On Fri, Feb 19, 2016 at 11:44 PM, Ronciak, John <john.ronc...@intel.com>
> wrote:
>
>> 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?
>>
> In my added code as a last resort in the e1000_clean_rx_irq function, I
read the ICR register and if it is asserted, I goto again, reading more
DMA:ed buffers. Delaying the code before the ICR read, helps the issue
quite a lot.
>
>> 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.
>>
>
>
--
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
