On Sun, Nov 5, 2017 at 9:44 PM, Andy Gospodarek <a...@greyhouse.net> wrote:
> From: Andy Gospodarek <go...@broadcom.com>
>
> This implements the changes needed for the bnxt_en driver to add support
> for adaptive interrupt moderation per ring.
>
> This does add additional counters in the receive path, but testing shows
> that any additional instructions are offset by throughput gain when the
> default configuration is for low latency.
>
> Signed-off-by: Andy Gospodarek <go...@broadcom.com>
> ---
> drivers/net/ethernet/broadcom/bnxt/Makefile | 2 +-
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 51
> +++++++++++++++++++++++
> drivers/net/ethernet/broadcom/bnxt/bnxt.h | 34 ++++++++++-----
> drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 7 ++++
> drivers/net/ethernet/broadcom/bnxt/bnxt_rx_am.c | 32 ++++++++++++++
> 5 files changed, 114 insertions(+), 12 deletions(-)
> create mode 100644 drivers/net/ethernet/broadcom/bnxt/bnxt_rx_am.c
>
> diff --git a/drivers/net/ethernet/broadcom/bnxt/Makefile
> b/drivers/net/ethernet/broadcom/bnxt/Makefile
> index 59c8ec9..1b0c78c 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/Makefile
> +++ b/drivers/net/ethernet/broadcom/bnxt/Makefile
> @@ -1,4 +1,4 @@
> obj-$(CONFIG_BNXT) += bnxt_en.o
>
> -bnxt_en-y := bnxt.o bnxt_sriov.o bnxt_ethtool.o bnxt_dcb.o bnxt_ulp.o
> bnxt_xdp.o bnxt_vfr.o bnxt_devlink.o
> +bnxt_en-y := bnxt.o bnxt_sriov.o bnxt_ethtool.o bnxt_dcb.o bnxt_ulp.o
> bnxt_xdp.o bnxt_vfr.o bnxt_devlink.o bnxt_rx_am.o
> bnxt_en-$(CONFIG_BNXT_FLOWER_OFFLOAD) += bnxt_tc.o
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> index 4e3d569..e1110d9 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> @@ -1482,6 +1482,7 @@ static int bnxt_rx_pkt(struct bnxt *bp, struct
> bnxt_napi *bnapi, u32 *raw_cons,
> u32 tmp_raw_cons = *raw_cons;
> u16 cfa_code, cons, prod, cp_cons = RING_CMP(tmp_raw_cons);
> struct bnxt_sw_rx_bd *rx_buf;
> + unsigned int pkts = 0;
> unsigned int len;
> u8 *data_ptr, agg_bufs, cmp_type;
> dma_addr_t dma_addr;
> @@ -1522,6 +1523,8 @@ static int bnxt_rx_pkt(struct bnxt *bp, struct
> bnxt_napi *bnapi, u32 *raw_cons,
>
> rc = -ENOMEM;
> if (likely(skb)) {
> + struct skb_shared_info *shinfo = skb_shinfo(skb);
> + pkts = shinfo->nr_frags;
> bnxt_deliver_skb(bp, bnapi, skb);
> rc = 1;
> }
> @@ -1645,6 +1648,8 @@ static int bnxt_rx_pkt(struct bnxt *bp, struct
> bnxt_napi *bnapi, u32 *raw_cons,
> rxr->rx_next_cons = NEXT_RX(cons);
>
> next_rx_no_prod:
> + cpr->rx_packets += pkts ? : 1;
> + cpr->rx_bytes += len;
These counters are in the RX fast path, including the XDP fast path.
If we are handling tens of millions of packets per second, every
packet has to incur the cost of these counters.
It will be much nicer if we can use the hardware counters instead.
