Menu
▾
▴
Re: [E1000-devel] 82599 latency increase with rx_missed_errors
|
From: Nishit S. <nis...@cy...> - 2013-08-05 17:03:19
|
Hi Alex,
Have you got chance to look at it ?
Rgds,
Nishit Shah.
On 7/26/2013 2:56 PM, Nishit Shah wrote:
>
> Hi Alex,
>
> Sorry for the delay.
>
> Basically, we are observing two problems.
>
> 1.) latency increase in case of small size packets when we get
> rx_missed_errors.
> - It is due to Rx FIFO as you have explained.
>
> 2.) latency increase with higher packet size at exact wire-line speed.
> - At 1024 to 1514 bytes packets, we are able to reach 9.9
> Gbps with around 50 microsecond per packet latency. But when load
> reaches 10 Gbps (wireline), latency increases to 500 microseconds.
> Here we are not observing rx_missed_errors and no_dma errors. Seems to
> be 100 mbps increase in load is shooting up latencies. We are
> suspecting something is happening at exact wireline speed but not able
> to figure it out.
>
> Rgds,
> Nishit Shah.
>
> On 7/17/2013 9:27 PM, Alexander Duyck wrote:
>> I'm not quite sure I understand what you are saying. So let me try to
>> paraphrase.
>>
>> It sounds like setting FdirPballoc to 3 did reduce latency. So that
>> tells us that the Rx FIFO is likely the source of the latency.
>>
>> The bit I don't understand is the part where you said you could not
>> "co-relate buffer bloat effect when CPU is free". If you are getting no
>> rx_missed_errors and no rx_no_dma_resources then you should be in the
>> lowest latency situation as there should be minimal buffering going on
>> the Rx FIFO. I would only expect to see the high latency situation in
>> the event where you start seeing rx_missed_errors as this indicates that
>> the Rx FIFO is full and as a result packets are being dropped before
>> they can enter the FIFO.
>>
>> Could you please clarify the test you are running, what results you are
>> seeing, and what results you are expecting? I'm not sure what it is you
>> are describing.
>>
>> Thanks,
>>
>> Alex
>>
>> On 07/16/2013 01:59 AM, Nishit Shah wrote:
>>> Hi Alex,
>>>
>>> Setting FdirPballoc to value 3 has cut down the latency by 40% as
>>> you mentioned but yet not co-relate buffer bloat effect when CPU is
>>> free. (Test of 1024 and 1514 bytes packets. - CPU is free by 50%. No
>>> rx_missed_errors and DROP_EN bit is set.)
>>>
>>> Rgds,
>>> Nishit Shah.
>>>
>>> On 5/18/2013 1:15 AM, Alexander Duyck wrote:
>>>> This sounds like standard buffer bloat due to the Rx FIFO.
>>>>
>>>> One thing you can try doing to test this is to use the FdirPballoc
>>>> module parameter setting of 3. Note this is a comma separated list of
>>>> values so if you have multiple ports it would be 3,3,3 where the
>>>> number
>>>> of entries is equal to the number of ports. By setting this value
>>>> to 3
>>>> you will reserve 256K of Rx FIFO space for flow director and
>>>> essentially
>>>> cut the Rx FIFO size by 3/8. As such you should see about a 40%
>>>> reduction in peak latency. The side effect is that you will be more
>>>> likely to drop traffic under bursty situations.
>>>>
>>>> Thanks,
>>>>
>>>> Alex
>>>>
>>>> On 05/17/2013 11:46 AM, Nishit Shah wrote:
>>>>> Thanks Donald,
>>>>>
>>>>> Point I want to put it,
>>>>>
>>>>> At 1024 to 1514 bytes packets, I am able to reach 9.9 Gbps with
>>>>> around 50 microsecond per packet latency. But when load reaches 10
>>>>> Gbps (wireline), latency increases to 500 microseconds. Seems bit
>>>>> odd that 100 mbps increase is shooting up latencies. I am suspecting
>>>>> something is happening at exact wireline speed but not able to
>>>>> figure it out..
>>>>>
>>>>> Is there any specific reason of it ?
>>>>>
>>>>> Rgds,
>>>>> Nishit shah
>>>>>
>>>>> On 17-May-2013, at 10:31 PM, "Skidmore, Donald
>>>>> C"<don...@in...> wrote:
>>>>>
>>>>>> Hey Nishit,
>>>>>>
>>>>>> The larger packets are less of a load on the PCIe bus so it can
>>>>>> handle more traffic before you start overloading it.
>>>>>>
>>>>>> If you are willing to sacrifice CPU cycles you could lower your
>>>>>> buffer size like you doing earlier. Of course I would expect that
>>>>>> to adversely affect the CPU usage.
>>>>>>
>>>>>> Thanks,
>>>>>> -Don Skidmore<don...@in...>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Nishit Shah [mailto:nis...@el...]
>>>>>>> Sent: Friday, May 17, 2013 5:22 AM
>>>>>>> To: Skidmore, Donald C
>>>>>>> Cc: e10...@li...
>>>>>>> Subject: Re: [E1000-devel] 82599 latency increase with
>>>>>>> rx_missed_errors
>>>>>>>
>>>>>>>
>>>>>>> Hi Donald,
>>>>>>>
>>>>>>> IOMMU is disabled.
>>>>>>> I do have one another observation. We don't have latency
>>>>>>> issue with
>>>>>>> higher packet sizes. But when we reach the wire-line on higher
>>>>>>> packet sizes,
>>>>>>> we are again seeing increase in latency. At that time CPU is free
>>>>>>> and no
>>>>>>> rx_missed and rx_no_dma errors.
>>>>>>> Is there anything trigger at that point ?
>>>>>>>
>>>>>>> Rgds,
>>>>>>> Nishit Shah.
>>>>>>>
>>>>>>> On 5/3/2013 4:24 AM, Skidmore, Donald C wrote:
>>>>>>>> Hey Nishit,
>>>>>>>>
>>>>>>>> Another engineer reminded me that IOMMU is never good for latency.
>>>>>>> You should also make sure that is disabled.
>>>>>>>> Thanks,
>>>>>>>> -Don Skidmore<don...@in...>
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Skidmore, Donald C
>>>>>>>>> Sent: Thursday, May 02, 2013 2:50 PM
>>>>>>>>> To: Nishit Shah
>>>>>>>>> Cc: e10...@li...
>>>>>>>>> Subject: RE: [E1000-devel] 82599 latency increase with
>>>>>>>>> rx_missed_errors
>>>>>>>>>
>>>>>>>>> Hey Nishit,
>>>>>>>>>
>>>>>>>>> I'm not sure what I can tell you. It looks like your device is
>>>>>>>>> loaded down with small packets we know this will overload the PCI
>>>>>>>>> bus, this will of course adversely event latency. You could try
>>>>>>>>> something like DCB. Put your traffic that needs low latency
>>>>>>>>> on one
>>>>>>>>> TC and the small packet traffic on another and use FC on that TC.
>>>>>>>>> This of course would require switches that support DCB and is
>>>>>>>>> assuming your small packet traffic and latency dependent are
>>>>>>>>> different flows. If they are not then you need some other
>>>>>>>>> mechanism to
>>>>>>> throttle your traffic before it saturates the bus.
>>>>>>>>> Thanks,
>>>>>>>>> -Don Skidmore<don...@in...>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Nishit Shah [mailto:nis...@el...]
>>>>>>>>>> Sent: Thursday, May 02, 2013 8:52 AM
>>>>>>>>>> To: Skidmore, Donald C
>>>>>>>>>> Cc: e10...@li...
>>>>>>>>>> Subject: Re: [E1000-devel] 82599 latency increase with
>>>>>>>>>> rx_missed_errors
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Don,
>>>>>>>>>>
>>>>>>>>>> Thanks for all the explanations. It will be a great help.
>>>>>>>>>> Can you suggest some pointers to look more into PCIe bus
>>>>>>>>>> configurations/tuning ?
>>>>>>>>>>
>>>>>>>>>> Rgds,
>>>>>>>>>> Nishit Shah.
>>>>>>>>>>
>>>>>>>>>> On 5/2/2013 3:41 AM, Skidmore, Donald C wrote:
>>>>>>>>>>> Hey Nishit,
>>>>>>>>>>>
>>>>>>>>>>> I replied inline below.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> -Don Skidmore<don...@in...>
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Nishit Shah [mailto:nis...@el...]
>>>>>>>>>>>> Sent: Tuesday, April 30, 2013 11:46 PM
>>>>>>>>>>>> To: Skidmore, Donald C
>>>>>>>>>>>> Cc: e10...@li...
>>>>>>>>>>>> Subject: Re: [E1000-devel] 82599 latency increase with
>>>>>>>>>>>> rx_missed_errors
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Don,
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/1/2013 3:40 AM, Skidmore, Donald C wrote:
>>>>>>>>>>>>> Hi Nishit,
>>>>>>>>>>>>>
>>>>>>>>>>>>> The rx_no_dma_resources means we are dropping packets because
>>>>>>>>> we
>>>>>>>>>>>> don't have any free descriptors in the RX Queue. While
>>>>>>>>>>>> rx_missed_errors are due to insufficient space to store an
>>>>>>>>>>>> ingress
>>>>>>>>>>>> packet, so basically we ran out of buffers or bandwidth on
>>>>>>>>>>>> the PCIe
>>>>>>> bus.
>>>>>>>>>>>> Thanks for the explanation. Is there any way to verify
>>>>>>>>>>>> whether we
>>>>>>>>>>>> are running out of buffers or bandwidth on the PCIe bus ?
>>>>>>>>>>> To a large extent these are transparent to the driver. You
>>>>>>>>>>> could
>>>>>>>>>>> put on FC
>>>>>>>>>> and if you still see that same number of rx_missed_errors this
>>>>>>>>>> would
>>>>>>>>>> infer that you are overloading your bus.
>>>>>>>>>>>> (ixgbe loading shows PCIe 5.0GT/s:Width
>>>>>>>>>>>> x8)
>>>>>>>>>>>>
>>>>>>>>>>>> # dmesg | grep "0000:06:00"
>>>>>>>>>>>> ixgbe 0000:06:00.0: PCI->APIC IRQ transform: INT C
>>>>>>>>>>>> -> IRQ 18
>>>>>>>>>>>> ixgbe 0000:06:00.0: setting latency timer to 64
>>>>>>>>>>>> ixgbe 0000:06:00.0: irq 40 for MSI/MSI-X
>>>>>>>>>>>> ixgbe 0000:06:00.0: irq 41 for MSI/MSI-X
>>>>>>>>>>>> ixgbe 0000:06:00.0: irq 42 for MSI/MSI-X
>>>>>>>>>>>> ixgbe 0000:06:00.0: (PCI Express:5.0GT/s:Width x8)
>>>>>>>>>>>> 00:90:fb:45:f1:76
>>>>>>>>>>>> ixgbe 0000:06:00.0: eth0: MAC: 2, PHY: 14, SFP+:
>>>>>>>>>>>> 5, PBA No:
>>>>>>>>>>>> ixgbe 0000:06:00.0: eth0: Enabled Features: RxQ: 2
>>>>>>>>>>>> TxQ:
>>>>>>>>>>>> 2 FdirHash
>>>>>>>>>> RSS
>>>>>>>>>>>> ixgbe 0000:06:00.0: eth0: Intel(R) 10 Gigabit
>>>>>>>>>>>> Network Connection
>>>>>>>>>>>> ixgbe 0000:06:00.1: PCI->APIC IRQ transform: INT D
>>>>>>>>>>>> -> IRQ 19
>>>>>>>>>>>> ixgbe 0000:06:00.1: setting latency timer to 64
>>>>>>>>>>>> ixgbe 0000:06:00.1: irq 43 for MSI/MSI-X
>>>>>>>>>>>> ixgbe 0000:06:00.1: irq 44 for MSI/MSI-X
>>>>>>>>>>>> ixgbe 0000:06:00.1: irq 45 for MSI/MSI-X
>>>>>>>>>>>> ixgbe 0000:06:00.1: (PCI Express:5.0GT/s:Width x8)
>>>>>>>>>>>> 00:90:fb:45:f1:77
>>>>>>>>>>>> ixgbe 0000:06:00.1: eth1: MAC: 2, PHY: 14, SFP+:
>>>>>>>>>>>> 6, PBA No:
>>>>>>>>>>>> ixgbe 0000:06:00.1: eth1: Enabled Features: RxQ: 2
>>>>>>>>>>>> TxQ:
>>>>>>>>>>>> 2 FdirHash
>>>>>>>>>> RSS
>>>>>>>>>>>> ixgbe 0000:06:00.1: eth1: Intel(R) 10 Gigabit
>>>>>>>>>>>> Network
>>>>>>>>>>>> Connection
>>>>>>>>>>>>
>>>>>>>>>>>> One another interesting observation.
>>>>>>>>>>>> When we have changed the packet buffer from 512 KB
>>>>>>>>>>>> to 128
>>>>>>>>>>>> KB (by changing rx_pb_size in ixgbe_82599.c), per packet
>>>>>>>>>>>> latency
>>>>>>>>>>>> is reduced from
>>>>>>>>>>>> 500 microseconds to 100 microseconds for 64 bytes packets.
>>>>>>>>>>>> Does it mean some kind of relation with size of packet
>>>>>>>>>>>> buffer ?
>>>>>>>>>>> This most likely shows that your small packet flow is
>>>>>>>>>>> overloading
>>>>>>>>>>> the PCIe
>>>>>>>>>> bus. Since shrinking the packet buffer would me it would take
>>>>>>>>>> less
>>>>>>>>>> time backfill while you wait on the saturated PCIe bus. So
>>>>>>>>>> when you
>>>>>>>>>> shrink the packet buffer you don't wait as long queued up for
>>>>>>>>>> PCIe
>>>>>>>>>> bus that can't handle your load. So I'm wouldn't think this
>>>>>>>>>> would
>>>>>>>>>> be a solution for you the real issue here is that the bus can't
>>>>>>>>>> keep
>>>>>>>>>> up with small
>>>>>>>>> packets loads.
>>>>>>>>>>>>> All that said when you see the rx_no_dma_resources errors is
>>>>>>>>>>>>> their rate
>>>>>>>>>>>> comparable with what you were seeing for rx_missed_errors?
>>>>>>>>>>>> Both
>>>>>>>>>>>> will lead to the same thing, dropped packets.
>>>>>>>>>>>>
>>>>>>>>>>>> I have find out the frame size from where we are
>>>>>>>>>>>> getting
>>>>>>>>>>>> rx_missed_errors and below is a rate at those sizes.
>>>>>>>>>>>>
>>>>>>>>>>>> frame size 110 bytes (avg. latency 45
>>>>>>>>>>>> microseconds)
>>>>>>>>>>>> - no rx_missed_errors.
>>>>>>>>>>>> - rx_no_dma_resources increase rate is 8200000/sec
>>>>>>>>>>>>
>>>>>>>>>>>> frame size 108 bytes (avg. latency 345
>>>>>>>>>>>> microseconds)
>>>>>>>>>>>> - rx_missed_errors increase rate is 207000/sec
>>>>>>>>>>>> - rx_no_dma_resources increase rate is 8300000/sec
>>>>>>>>>>> I assume you crossed some boundary here with the lower frame
>>>>>>>>>>> size
>>>>>>>>>>> you
>>>>>>>>>> have more PCI transaction for the same data throughput. So
>>>>>>>>>> once you
>>>>>>>>>> crossed to 108 bytes you start running out of PCIe bandwidth.
>>>>>>>>>>>>> Also what does 'lspci -vvv' show, I'm looking to see if
>>>>>>>>>>>>> you are
>>>>>>>>>>>>> getting the full
>>>>>>>>>>>> PCIe bandwidth. You could also try to turn on FC which should
>>>>>>>>>>>> lower these types of overflow occurrences.
>>>>>>>>>>>>
>>>>>>>>>>>> Enabling flow control is even increasing the latency.
>>>>>>>>>>>> Seems
>>>>>>>>>>>> to be tester machine is not understanding the PAUSE frames
>>>>>>>>>>>> and FC
>>>>>>>>>>>> also clears the DROP_EN bit that is again increasing the
>>>>>>>>>>>> latency.
>>>>>>>>>>>> lspci -vvv output is attached with the mail.
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> -Don Skidmore<don...@in...>
>>>>>>>>>>>> Rgds,
>>>>>>>>>>>> Nishit Shah.
>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Nishit Shah [mailto:nis...@el...]
>>>>>>>>>>>>>> Sent: Tuesday, April 30, 2013 9:07 AM
>>>>>>>>>>>>>> To: e10...@li...
>>>>>>>>>>>>>> Subject: [E1000-devel] 82599 latency increase with
>>>>>>>>>>>>>> rx_missed_errors
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We are measuring packet latencies at various packet
>>>>>>>>>>>>>> sizes
>>>>>>>>>>>>>> (64 bytes to
>>>>>>>>>>>>>> 1518 bytes) with 82599 card with ixgbe driver 3.7.21.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Setup:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Spirent test center sender
>>>>>>>>>>>>>> machine with 82599
>>>>>>>>>>>>>> (ixgbe 3.7.21 and vanilla 2.6.39.4) Spirent test
>>>>>>>>>>>>>> center receiver
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 10 G<------------------------>
>>>>>>>>>>>>>> 10G
>>>>>>>>>>>>>> 10G<------------------------------> 10G
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When we don't have an increase in
>>>>>>>>>>>>>> "rx_missed_errors" and
>>>>>>>>>>>>>> "rx_no_dma_resources", we are getting per packet latency
>>>>>>>>>>>>>> around
>>>>>>>>>>>>>> 40-70 microseconds. ("rx_no_buffer_count" is not increasing)
>>>>>>>>>>>>>> When we have an increase in
>>>>>>>>>>>>>> "rx_no_dma_resources", we
>>>>>>>>>>>>>> are still
>>>>>>>>>>>> getting
>>>>>>>>>>>>>> per packet latency around 40-70 microseconds.
>>>>>>>>>>>>>> ("rx_no_buffer_count" is not increasing)
>>>>>>>>>>>>>> When we have an increase in "rx_missed_errors",
>>>>>>>>>>>>>> we are
>>>>>>>>>>>>>> getting per packet latency around 500 microseconds.
>>>>>>>>>>>>>> (rx_no_buffer_count is not
>>>>>>>>>>>>>> increasing)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is there any specific reason for latency
>>>>>>>>>>>>>> increase when
>>>>>>>>>>>> "rx_missed_errors"
>>>>>>>>>>>>>> are increased ?
>>>>>>>>>>>>>> Is there a way to control it ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Below is a machine detail.
>>>>>>>>>>>>>>
>>>>>>> ==========================================================
>>>>>>>>>>>>>> ===============================================
>>>>>>>>>>>>>> Machine details.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> CPU: Dual Core Intel(R) Celeron(R) CPU
>>>>>>>>>>>>>> G540 @ 2.50GHz
>>>>>>>>>>>>>> Memory: 2 GB
>>>>>>>>>>>>>> kernel: vanilla 2.6.39.4
>>>>>>>>>>>>>> Interface tuning parameters:
>>>>>>>>>>>>>> Auto Negotiation is off (DROP_EN is
>>>>>>>>>>>>>> set.)
>>>>>>>>>>>>>> ethtool -G eth0 rx 64 tx 128 ; ethtool
>>>>>>>>>>>>>> -G eth1 rx 64 tx 128
>>>>>>>>>>>>>> rx-usecs is set to 50.
>>>>>>>>>>>>>> ethtool and lspci for bus information:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> # ethtool -i eth0
>>>>>>>>>>>>>> driver: ixgbe
>>>>>>>>>>>>>> version: 3.7.21-NAPI
>>>>>>>>>>>>>> firmware-version: 0x80000345
>>>>>>>>>>>>>> bus-info: 0000:06:00.0
>>>>>>>>>>>>>> #
>>>>>>>>>>>>>> # ethtool -i eth1
>>>>>>>>>>>>>> driver: ixgbe
>>>>>>>>>>>>>> version: 3.7.21-NAPI
>>>>>>>>>>>>>> firmware-version: 0x80000345
>>>>>>>>>>>>>> bus-info: 0000:06:00.1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 06:00.0 Class 0200: Device 8086:10fb (rev 01)
>>>>>>>>>>>>>> Subsystem: Device 15bb:30e0
>>>>>>>>>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle-
>>>>>>>>>>>>>> MemWINV-
>>>>>>>>>>>> VGASnoop-
>>>>>>>>>>>>>> ParErr- Stepping- SERR- FastB2B- DisINTx+
>>>>>>>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr-
>>>>>>>>>>>>>> DEVSEL=fast
>>>>>>>>>>>>>>> TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>>>>>>>>>>>>> Latency: 0, Cache Line Size: 64 bytes
>>>>>>>>>>>>>> Interrupt: pin A routed to IRQ 18
>>>>>>>>>>>>>> Region 0: Memory at f7520000 (64-bit,
>>>>>>>>>>>>>> non-prefetchable)
>>>>>>>>>>>> [size=128K]
>>>>>>>>>>>>>> Region 2: I/O ports at 8020 [size=32]
>>>>>>>>>>>>>> Region 4: Memory at f7544000 (64-bit,
>>>>>>>>>>>>>> non-prefetchable)
>>>>>>>>>>>> [size=16K]
>>>>>>>>>>>>>> Capabilities: [40] Power Management
>>>>>>>>>>>>>> version 3
>>>>>>>>>>>>>> Flags: PMEClk- DSI+ D1- D2-
>>>>>>>>>>>>>> AuxCurrent=0mA
>>>>>>>>>>>>>> PME(D0+,D1-,D2-,D3hot+,D3cold-)
>>>>>>>>>>>>>> Status: D0 NoSoftRst- PME-Enable-
>>>>>>>>>>>>>> DSel=0 DScale=1
>>>>>>> PME-
>>>>>>>>>>>>>> Capabilities: [50] MSI: Enable- Count=1/1
>>>>>>>>>>>>>> Maskable+ 64bit+
>>>>>>>>>>>>>> Address: 0000000000000000 Data: 0000
>>>>>>>>>>>>>> Masking: 00000000 Pending: 00000000
>>>>>>>>>>>>>> Capabilities: [70] MSI-X: Enable+ Count=64
>>>>>>>>>>>>>> Masked-
>>>>>>>>>>>>>> Vector table: BAR=4 offset=00000000
>>>>>>>>>>>>>> PBA: BAR=4 offset=00002000
>>>>>>>>>>>>>> Capabilities: [a0] Express (v2) Endpoint,
>>>>>>>>>>>>>> MSI 00
>>>>>>>>>>>>>> DevCap: MaxPayload 512 bytes,
>>>>>>>>>>>>>> PhantFunc 0,
>>>>>>>>>>>>>> Latency L0s<512ns,
>>>>>>>>>>>> L1
>>>>>>>>>>>>>> <64us
>>>>>>>>>>>>>> ExtTag- AttnBtn- AttnInd- PwrInd-
>>>>>>>>>>>>>> RBE+ FLReset+
>>>>>>>>>>>>>> DevCtl: Report errors: Correctable-
>>>>>>>>>>>>>> Non-Fatal-
>>>>>>>>>>>>>> Fatal-
>>>>>>>>>>>>>> Unsupported-
>>>>>>>>>>>>>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr-
>>>>>>>>>>>>>> NoSnoop+
>>>>>>>>> FLReset-
>>>>>>>>>>>>>> MaxPayload 128 bytes, MaxReadReq
>>>>>>>>>>>>>> 512 bytes
>>>>>>>>>>>>>> DevSta: CorrErr+ UncorrErr- FatalErr-
>>>>>>>>>>>>>> UnsuppReq+
>>>>>>>>>>>>>> AuxPwr- TransPend-
>>>>>>>>>>>>>> LnkCap: Port #1, Speed 5GT/s, Width x8,
>>>>>>>>>>>>>> ASPM
>>>>>>>>>>>>>> L0s, Latency
>>>>>>>>>>>> L0<2us,
>>>>>>>>>>>>>> L1<32us
>>>>>>>>>>>>>> ClockPM- Surprise- LLActRep- BwNot-
>>>>>>>>>>>>>> LnkCtl: ASPM Disabled; RCB 64 bytes
>>>>>>>>>>>>>> Disabled-
>>>>>>>>>>>>>> Retrain-
>>>>>>>>>>>>>> CommClk-
>>>>>>>>>>>>>> ExtSynch- ClockPM- AutWidDis-
>>>>>>>>>>>>>> BWInt- AutBWInt-
>>>>>>>>>>>>>> LnkSta: Speed 5GT/s, Width x8, TrErr-
>>>>>>>>>>>>>> Train-
>>>>>>>>>>>>>> SlotClk+
>>>>>>>>>>>>>> DLActive- BWMgmt- ABWMgmt-
>>>>>>>>>>>>>> DevCap2: Completion Timeout: Range
>>>>>>>>>>>>>> ABCD,
>>>>>>> TimeoutDis+
>>>>>>>>>>>>>> DevCtl2: Completion Timeout: 50us to
>>>>>>>>>>>>>> 50ms, TimeoutDis-
>>>>>>>>>>>>>> LnkCtl2: Target Link Speed: 5GT/s,
>>>>>>>>>>>>>> EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
>>>>>>>>>>>>>> Transmit Margin: Normal Operating
>>>>>>>>>>>>>> Range,
>>>>>>>>>>>>>> EnterModifiedCompliance- ComplianceSOS-
>>>>>>>>>>>>>> Compliance De-emphasis: -6dB
>>>>>>>>>>>>>> LnkSta2: Current De-emphasis Level:
>>>>>>>>>>>>>> -6dB
>>>>>>>>>>>>>> Capabilities: [e0] Vital Product Data
>>>>>>>>>>>>>> Unknown small resource type 06, will
>>>>>>>>>>>>>> not decode more.
>>>>>>>>>>>>>> Kernel driver in use: ixgbe
>>>>>>>>>>>>>> Kernel modules: ixgbe
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 06:00.1 Class 0200: Device 8086:10fb (rev 01)
>>>>>>>>>>>>>> Subsystem: Device 15bb:30e0
>>>>>>>>>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle-
>>>>>>>>>>>>>> MemWINV-
>>>>>>>>>>>> VGASnoop-
>>>>>>>>>>>>>> ParErr- Stepping- SERR- FastB2B- DisINTx+
>>>>>>>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr-
>>>>>>>>>>>>>> DEVSEL=fast
>>>>>>>>>>>>>>> TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>>>>>>>>>>>>> Latency: 0, Cache Line Size: 64 bytes
>>>>>>>>>>>>>> Interrupt: pin B routed to IRQ 19
>>>>>>>>>>>>>> Region 0: Memory at f7500000 (64-bit,
>>>>>>>>>>>>>> non-prefetchable)
>>>>>>>>>>>> [size=128K]
>>>>>>>>>>>>>> Region 2: I/O ports at 8000 [size=32]
>>>>>>>>>>>>>> Region 4: Memory at f7540000 (64-bit,
>>>>>>>>>>>>>> non-prefetchable)
>>>>>>>>>>>> [size=16K]
>>>>>>>>>>>>>> Capabilities: [40] Power Management
>>>>>>>>>>>>>> version 3
>>>>>>>>>>>>>> Flags: PMEClk- DSI+ D1- D2-
>>>>>>>>>>>>>> AuxCurrent=0mA
>>>>>>>>>>>>>> PME(D0+,D1-,D2-,D3hot+,D3cold-)
>>>>>>>>>>>>>> Status: D0 NoSoftRst- PME-Enable-
>>>>>>>>>>>>>> DSel=0 DScale=1
>>>>>>> PME-
>>>>>>>>>>>>>> Capabilities: [50] MSI: Enable- Count=1/1
>>>>>>>>>>>>>> Maskable+ 64bit+
>>>>>>>>>>>>>> Address: 0000000000000000 Data: 0000
>>>>>>>>>>>>>> Masking: 00000000 Pending: 00000000
>>>>>>>>>>>>>> Capabilities: [70] MSI-X: Enable+ Count=64
>>>>>>>>>>>>>> Masked-
>>>>>>>>>>>>>> Vector table: BAR=4 offset=00000000
>>>>>>>>>>>>>> PBA: BAR=4 offset=00002000
>>>>>>>>>>>>>> Capabilities: [a0] Express (v2) Endpoint,
>>>>>>>>>>>>>> MSI 00
>>>>>>>>>>>>>> DevCap: MaxPayload 512 bytes,
>>>>>>>>>>>>>> PhantFunc 0,
>>>>>>>>>>>>>> Latency L0s<512ns,
>>>>>>>>>>>> L1
>>>>>>>>>>>>>> <64us
>>>>>>>>>>>>>> ExtTag- AttnBtn- AttnInd- PwrInd-
>>>>>>>>>>>>>> RBE+ FLReset+
>>>>>>>>>>>>>> DevCtl: Report errors: Correctable-
>>>>>>>>>>>>>> Non-Fatal-
>>>>>>>>>>>>>> Fatal-
>>>>>>>>>>>>>> Unsupported-
>>>>>>>>>>>>>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr-
>>>>>>>>>>>>>> NoSnoop+
>>>>>>>>> FLReset-
>>>>>>>>>>>>>> MaxPayload 128 bytes, MaxReadReq
>>>>>>>>>>>>>> 512 bytes
>>>>>>>>>>>>>> DevSta: CorrErr+ UncorrErr- FatalErr-
>>>>>>>>>>>>>> UnsuppReq+
>>>>>>>>>>>>>> AuxPwr- TransPend-
>>>>>>>>>>>>>> LnkCap: Port #1, Speed 5GT/s, Width x8,
>>>>>>>>>>>>>> ASPM
>>>>>>>>>>>>>> L0s, Latency
>>>>>>>>>>>> L0<2us,
>>>>>>>>>>>>>> L1<32us
>>>>>>>>>>>>>> ClockPM- Surprise- LLActRep- BwNot-
>>>>>>>>>>>>>> LnkCtl: ASPM Disabled; RCB 64 bytes
>>>>>>>>>>>>>> Disabled-
>>>>>>>>>>>>>> Retrain-
>>>>>>>>>>>>>> CommClk-
>>>>>>>>>>>>>> ExtSynch- ClockPM- AutWidDis-
>>>>>>>>>>>>>> BWInt- AutBWInt-
>>>>>>>>>>>>>> LnkSta: Speed 5GT/s, Width x8, TrErr-
>>>>>>>>>>>>>> Train-
>>>>>>>>>>>>>> SlotClk+
>>>>>>>>>>>>>> DLActive- BWMgmt- ABWMgmt-
>>>>>>>>>>>>>> DevCap2: Completion Timeout: Range
>>>>>>>>>>>>>> ABCD,
>>>>>>> TimeoutDis+
>>>>>>>>>>>>>> DevCtl2: Completion Timeout: 50us to
>>>>>>>>>>>>>> 50ms, TimeoutDis-
>>>>>>>>>>>>>> LnkCtl2: Target Link Speed: 2.5GT/s,
>>>>>>>>>>>>>> EnterCompliance- SpeedDis-
>>>>>>>>>>>> ,
>>>>>>>>>>>>>> Selectable De-emphasis: -6dB
>>>>>>>>>>>>>> Transmit Margin: Normal Operating
>>>>>>>>>>>>>> Range,
>>>>>>>>>>>>>> EnterModifiedCompliance- ComplianceSOS-
>>>>>>>>>>>>>> Compliance De-emphasis: -6dB
>>>>>>>>>>>>>> LnkSta2: Current De-emphasis Level:
>>>>>>>>>>>>>> -6dB
>>>>>>>>>>>>>> Capabilities: [e0] Vital Product Data
>>>>>>>>>>>>>> Unknown small resource type 06, will
>>>>>>>>>>>>>> not decode more.
>>>>>>>>>>>>>> Kernel driver in use: ixgbe
>>>>>>>>>>>>>> Kernel modules: ixgbe
>>>>>>>>>>>>>>
>>>>>>> ==========================================================
>>>>>>>>>>>>>> ===============================================
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Rgds,
>>>>>>>>>>>>>> Nishit Shah.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> ----------- Introducing AppDynamics Lite, a free
>>>>>>>>>>>>>> troubleshooting
>>>>>>>>>>>>>> tool for Java/.NET
>>>>>>>>>>>> Get
>>>>>>>>>>>>>> 100% visibility into your production application - at no
>>>>>>>>>>>>>> cost.
>>>>>>>>>>>>>> Code-level diagnostics for performance bottlenecks with<2%
>>>>>>>>>>>>>> overhead Download for free and get started
>>>>>>>>>>>>>> troubleshooting in
>>>>>>>>> minutes.
>>>>>>>>>>>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> E1000-devel mailing list
>>>>>>>>>>>>>> E10...@li...
>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/e1000-devel
>>>>>>>>>>>>>> To learn more about Intel® Ethernet, visit
>>>>>>>>>>>>>> http://communities.intel.com/community/wired
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> AlienVault Unified Security Management (USM) platform delivers
>>>>> complete
>>>>> security visibility with the essential security capabilities. Easily
>>>>> and
>>>>> efficiently configure, manage, and operate all of your security
>>>>> controls
>>>>> from a single console and one unified framework. Download a free
>>>>> trial.
>>>>> http://p.sf.net/sfu/alienvault_d2d
>>>>> _______________________________________________
>>>>> E1000-devel mailing list
>>>>> E10...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/e1000-devel
>>>>> To learn more about Intel® Ethernet, visit
>>>>> http://communities.intel.com/community/wired
>
|
