Jonathan,
I suggest you review the 82598 and 82599 datasheets as they contain most
of the information you are looking for in regards to the register set.
They are available at e1000.sf.net.
The 82599 supports 16 QPRDC registers. These are mapped registers for
the queues and are not related to the packet buffers.
In regards to the QBTC registers there are two different sets. The
82598 I believe supported only one register and was mapped using the 0x8
offset, whereas the newer register that was split in half for 82599
supports a 0x40 byte offset.
Thanks,
Alex
On 07/14/2011 04:19 AM, Lynch, Jonathan wrote:
> Hi Alex,
>
> One last question on QPRDC register along with the other queued
> packet/bytes registers. There are 16 values for this register (0...15)
> but on the receive side there is a max of 8 packet buffers when using
> DCB, correct? Im just wondering why there is 16 as opposed to 8 values?
>
> in ixgbe_update_stats(), Queue Packets Received Drop Count — QPRDC[n]
> is updated as follows:
> for (i = 0; i < 16; i++) should this be i<8 as i<8 is also used for
> the other queue packets/bytes registers below??
> adapter->hw_rx_no_dma_resources += IXGBE_READ_REG(hw,
> IXGBE_QPRDC(i));
>
> Also
> Queue Packets Received Count — QPRC[n]
> Queue Bytes Received Count Low — QBRC_L[n]
> etc are updated as follows:
>
> for (i = 0; i < 8; i++) {
> hwstats->qptc[i] += IXGBE_READ_REG(hw, IXGBE_QPTC(i));
> hwstats->qbtc[i] += IXGBE_READ_REG(hw, IXGBE_QBTC(i));
> hwstats->qprc[i] += IXGBE_READ_REG(hw, IXGBE_QPRC(i));
> hwstats->qbrc[i] += IXGBE_READ_REG(hw, IXGBE_QBRC(i));
>
>
> in ixgbe_type.h in the latest driver there seems to be a bug in the
> IXGBE_QBTC macro
> #define IXGBE_QPRC(_i) (0x01030 + ((_i) * 0x40)) /* 16 of these */
> #define IXGBE_QPTC(_i) (0x06030 + ((_i) * 0x40)) /* 16 of these */
> #define IXGBE_QBRC(_i) (0x01034 + ((_i) * 0x40)) /* 16 of these */
> #define IXGBE_QBTC(_i) (0x06034 + ((_i) * 0x40)) /* 16 of these */ ->
> should this not be IXGBE_QBTC(_i) (0x08700 + ((_i) * 0x8))....ie same
> as IXGBE_QBTC_L ?????
> #define IXGBE_QBRC_L(_i) (0x01034 + ((_i) * 0x40)) /* 16 of these */
> #define IXGBE_QBRC_H(_i) (0x01038 + ((_i) * 0x40)) /* 16 of these */
> #define IXGBE_QPRDC(_i) (0x01430 + ((_i) * 0x40)) /* 16 of these */
> #define IXGBE_QBTC_L(_i) (0x08700 + ((_i) * 0x8)) /* 16 of these */
> #define IXGBE_QBTC_H(_i) (0x08704 + ((_i) * 0x8)) /* 16 of these */
>
> Thanks
> Jonathan
>
> On 7 July 2011 22:43, Lynch, Jonathan
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Alex,
>
> Thanks, the register "Queue Packets Received Drop Count — QPRDC"
> which updates that stat seems to be what Im looking for.
>
> Regards
> Jonathan
>
>
> On 7 July 2011 18:44, Alexander Duyck <[email protected]
> <mailto:[email protected]>> wrote:
>
> If the DROP_EN bit is set you should see the
> rx_no_dma_resources counter start to increment if packets are
> being dropped due to a lack of DMA resources.
>
> Thanks,
>
> Alex
>
>
> On 07/07/2011 10:04 AM, Lynch, Jonathan wrote:
>
> Hi Alex,
>
> If SRRCTL.DROP_EN happens to be set, is there any other
> register which counts the packets which are "dropped at
> the head of the FIFO for not having a free descriptor." ?
>
> Thanks
> Jonathan
>
> On 7 July 2011 16:57, Alexander Duyck
> <[email protected]
> <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
>
> On 07/06/2011 03:40 AM, Lynch, Jonathan wrote:
>
> Hi Alex,
>
> Quick question on when RXMPC is incremented on
> 82599 hardware.
> Does the hardware check if RDH[n] == RDT[n]. If
> this is true
> there are no descriptors free, hence packet
> dropped, RXMPC[n]++?
>
> 8.2.3.23.4 Rx Missed Packets Count — RXMPC[n]
> (0x03FA0 + 4*n,
> n=0...7; RC) DBU-Rx
> Register ‘n’ counts the number of missed packets
> per packet
> buffer ‘n’.
> Packets are missed when the receive FIFO has
> insufficient
> space to store the incoming
> packet. This may be caused due to insufficient buffers
> allocated, or because there is
> insufficient bandwidth on the IO bus. Events
> setting this
> counter also set the receiver
> overrun interrupt (RXO). These registers do not
> increment if
> receive is not enabled and
> count only packets that would have been posted to
> the SW driver.
>
> Regards
> Jonathan
>
>
> RXMPC is incremented any time the RX FIFO is filled and
> a packet
> is received that cannot be placed on the FIFO. It does
> not check
> RDH/RDT values. There are two ways to end up with the
> RX FIFO
> being filled.
>
> The first way to fill the RX FIFO is if the software
> cannot keep
> up. This results in the RDH[n] == RDT[n] scenerio that you
> described above, but what this triggers is packets to start
> waiting in the RX FIFO for free space. In order for
> this to occur
> you also need to have the SRRCTL.DROP_EN bit cleared in
> order to
> prevent the packet from being dropped at the head of
> the FIFO for
> not having a free descriptor.
>
> The second way to fill the RX FIFO is if the PCIe bus
> is somehow
> limited and cannot move the packets from the RX FIFO
> into the
> system memory fast enough. This can happen if for
> example you are
> on a x4 or smaller PCIe link, or possibly on a PCIe gen
> 1 link.
>
> Thanks,
>
> Alex
>
>
>
>
>
------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
E1000-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
