> On Oct 24, 2017, at 11:20 AM, Lennart Sorensen
> wrote:
>
> On Tue, Sep 19, 2017 at 09:41:02PM +0200, Benjamin Poirier wrote:
>> On 2017/09/19 12:38, Philip Prindeville wrote:
>>> Hi.
>>>
>>> We’ve been running this patchset (all 5) for about as long as they’ve been
>>> under review… about
On Tue, Sep 19, 2017 at 09:41:02PM +0200, Benjamin Poirier wrote:
> On 2017/09/19 12:38, Philip Prindeville wrote:
> > Hi.
> >
> > We’ve been running this patchset (all 5) for about as long as they’ve been
> > under review… about 2 months. And in a burn-in lab with heavy traffic.
> >
> > We’ve
On 2017/09/19 12:38, Philip Prindeville wrote:
> Hi.
>
> We’ve been running this patchset (all 5) for about as long as they’ve been
> under review… about 2 months. And in a burn-in lab with heavy traffic.
>
> We’ve not seen a single link-flap in hundreds of ours of saturated traffic.
>
> Would
Hi.
We’ve been running this patchset (all 5) for about as long as they’ve been
under review… about 2 months. And in a burn-in lab with heavy traffic.
We’ve not seen a single link-flap in hundreds of ours of saturated traffic.
Would love to see some resolution soon on this as we don’t want to s
> Subject: [Intel-wired-lan] [PATCH 5/5] e1000e: Avoid receiver overrun
> interrupt bursts
>
> When e1000e_poll() is not fast enough to keep up with incoming traffic, the
> adapter (when operating in msix mode) raises the Other interrupt to signal
> Receiver Overrun.
>
>
On 2017/07/21 11:36, Benjamin Poirier wrote:
> When e1000e_poll() is not fast enough to keep up with incoming traffic, the
> adapter (when operating in msix mode) raises the Other interrupt to signal
> Receiver Overrun.
>
> This is a double problem because 1) at the moment e1000_msix_other()
> ass
> On Aug 11, 2017, at 8:13 PM, Philip Prindeville
> wrote:
>
>>
>> On Jul 21, 2017, at 12:48 PM, Lennart Sorensen
>> wrote:
>>
>> On Fri, Jul 21, 2017 at 11:36:27AM -0700, Benjamin Poirier wrote:
>>> When e1000e_poll() is not fast enough to keep up with incoming traffic, the
>>> adapter (wh
> On Jul 21, 2017, at 12:48 PM, Lennart Sorensen
> wrote:
>
> On Fri, Jul 21, 2017 at 11:36:27AM -0700, Benjamin Poirier wrote:
>> When e1000e_poll() is not fast enough to keep up with incoming traffic, the
>> adapter (when operating in msix mode) raises the Other interrupt to signal
>> Receive
On Fri, Jul 21, 2017 at 11:36:27AM -0700, Benjamin Poirier wrote:
> When e1000e_poll() is not fast enough to keep up with incoming traffic, the
> adapter (when operating in msix mode) raises the Other interrupt to signal
> Receiver Overrun.
>
> This is a double problem because 1) at the moment e10
When e1000e_poll() is not fast enough to keep up with incoming traffic, the
adapter (when operating in msix mode) raises the Other interrupt to signal
Receiver Overrun.
This is a double problem because 1) at the moment e1000_msix_other()
assumes that it is only called in case of Link Status Change
10 matches
Mail list logo
