> >
> > Now my question is how big is the induced latency.
> >
> After the wake-up timer is armed, the e1000e driver handles the network link
> configuration after the NIC was reset. When the function
> "e1000e_update_mc_addr_list_generic" is called, the MTA table is rewritten (the
> writing of this table consists of >70 MMIO writes followed by a read).
>
> We see the hrtimer entry expire at the value 73712084997 near the bottom of the
> trace.
>
> 73712084997ns - 73712055622ns = 29375ns
>
> So, we see a ~29us latency, in comparison to a good case where we see about
> 1us.
I have a similar problem, but in my case the hardware latency is the problem.
We are executing DMA transfers over PCIe for fieldbus communication over
Ethernet (PCIe target is own fieldbus FPGA, not the e1000e).
Usually the DMA transfers start with a maximum delay of ~25us. But in case of
link down and up on the e1000e controller the worst case delay is 65us. This
violates our real-time deadlines. DMA transfer is triggered by the hardware and
delay is also measured by the hardware, no software is involved. With the following
patch the problem disappears:
@@ -376,9 +376,10 @@ void e1000e_update_mc_addr_list_generic(struct e1000_hw *hw,
}
/* replace the entire MTA table */
- for (i = hw->mac.mta_reg_count - 1; i >= 0; i--)
+ for (i = hw->mac.mta_reg_count - 1; i >= 0; i--) {
E1000_WRITE_REG_ARRAY(hw, E1000_MTA, i, hw->mac.mta_shadow[i]);
- e1e_flush();
+ e1e_flush();
+ }
}
/**
What is the state of your patch for the e1000e driver?
regards, gerhard
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
