New upstream version 17.11-rc3

[deb_dpdk.git] / drivers / net / qede / base / ecore_vfpf_if.h

diff --git a/drivers/net/qede/base/ecore_vfpf_if.h b/drivers/net/qede/base/ecore_vfpf_if.h
index 6618442..3ccc766 100644 (file)
--- a/drivers/net/qede/base/ecore_vfpf_if.h
+++ b/drivers/net/qede/base/ecore_vfpf_if.h
@@ -19,13 +19,14 @@
  *
  **/
 struct vf_pf_resc_request {
-       u8  num_rxqs;
-       u8  num_txqs;
-       u8  num_sbs;
-       u8  num_mac_filters;
-       u8  num_vlan_filters;
-       u8  num_mc_filters; /* No limit  so superfluous */
-       u16 padding;
+       u8 num_rxqs;
+       u8 num_txqs;
+       u8 num_sbs;
+       u8 num_mac_filters;
+       u8 num_vlan_filters;
+       u8 num_mc_filters; /* No limit  so superfluous */
+       u8 num_cids;
+       u8 padding;
 };
 
 struct hw_sb_info {
@@ -92,6 +93,20 @@ struct vfpf_acquire_tlv {
 /* VF pre-FP hsi version */
 #define VFPF_ACQUIRE_CAP_PRE_FP_HSI    (1 << 0)
 #define VFPF_ACQUIRE_CAP_100G          (1 << 1) /* VF can support 100g */
+
+       /* A requirement for supporting multi-Tx queues on a single queue-zone,
+        * VF would pass qids as additional information whenever passing queue
+        * references.
+        * TODO - due to the CID limitations in Bar0, VFs currently don't pass
+        * this, and use the legacy CID scheme.
+        */
+#define VFPF_ACQUIRE_CAP_QUEUE_QIDS    (1 << 2)
+
+       /* The VF is using the physical bar. While this is mostly internal
+        * to the VF, might affect the number of CIDs supported assuming
+        * QUEUE_QIDS is set.
+        */
+#define VFPF_ACQUIRE_CAP_PHYSICAL_BAR  (1 << 3)
                u64 capabilities;
                u8 fw_major;
                u8 fw_minor;
@@ -170,6 +185,9 @@ struct pfvf_acquire_resp_tlv {
 #endif
 #define PFVF_ACQUIRE_CAP_POST_FW_OVERRIDE      (1 << 2)
 
+       /* PF expects queues to be received with additional qids */
+#define PFVF_ACQUIRE_CAP_QUEUE_QIDS            (1 << 3)
+
                u16 db_size;
                u8  indices_per_sb;
                u8 os_type;
@@ -178,7 +196,8 @@ struct pfvf_acquire_resp_tlv {
                u16 chip_rev;
                u8 dev_type;
 
-               u8 padding;
+               /* Doorbell bar size configured in HW: log(size) or 0 */
+               u8 bar_size;
 
                struct pfvf_stats_info stats_info;
 
@@ -210,7 +229,8 @@ struct pfvf_acquire_resp_tlv {
                u8      num_mac_filters;
                u8      num_vlan_filters;
                u8      num_mc_filters;
-               u8      padding[2];
+               u8      num_cids;
+               u8      padding;
        } resc;
 
        u32 bulletin_size;
@@ -223,6 +243,16 @@ struct pfvf_start_queue_resp_tlv {
        u8 padding[4];
 };
 
+/* Extended queue information - additional index for reference inside qzone.
+ * If commmunicated between VF/PF, each TLV relating to queues should be
+ * extended by one such [or have a future base TLV that already contains info].
+ */
+struct vfpf_qid_tlv {
+       struct channel_tlv      tl;
+       u8                      qid;
+       u8                      padding[3];
+};
+
 /* Setup Queue */
 struct vfpf_start_rxq_tlv {
        struct vfpf_first_tlv   first_tlv;
@@ -265,7 +295,15 @@ struct vfpf_stop_rxqs_tlv {
        struct vfpf_first_tlv   first_tlv;
 
        u16                     rx_qid;
+
+       /* While the API supports multiple Rx-queues on a single TLV
+        * message, in practice older VFs always used it as one [ecore].
+        * And there are PFs [starting with the CHANNEL_TLV_QID] which
+        * would start assuming this is always a '1'. So in practice this
+        * field should be considered deprecated and *Always* set to '1'.
+        */
        u8                      num_rxqs;
+
        u8                      cqe_completion;
        u8                      padding[4];
 };
@@ -275,6 +313,13 @@ struct vfpf_stop_txqs_tlv {
        struct vfpf_first_tlv   first_tlv;
 
        u16                     tx_qid;
+
+       /* While the API supports multiple Tx-queues on a single TLV
+        * message, in practice older VFs always used it as one [ecore].
+        * And there are PFs [starting with the CHANNEL_TLV_QID] which
+        * would start assuming this is always a '1'. So in practice this
+        * field should be considered deprecated and *Always* set to '1'.
+        */
        u8                      num_txqs;
        u8                      padding[5];
 };
@@ -465,6 +510,19 @@ struct vfpf_update_coalesce {
        u8 padding[2];
 };
 
+struct vfpf_read_coal_req_tlv {
+       struct vfpf_first_tlv first_tlv;
+       u16 qid;
+       u8 is_rx;
+       u8 padding[5];
+};
+
+struct pfvf_read_coal_resp_tlv {
+       struct pfvf_tlv hdr;
+       u16 coal;
+       u8 padding[6];
+};
+
 union vfpf_tlvs {
        struct vfpf_first_tlv                   first_tlv;
        struct vfpf_acquire_tlv                 acquire;
@@ -478,6 +536,7 @@ union vfpf_tlvs {
        struct vfpf_ucast_filter_tlv            ucast_filter;
        struct vfpf_update_tunn_param_tlv       tunn_param_update;
        struct vfpf_update_coalesce             update_coalesce;
+       struct vfpf_read_coal_req_tlv           read_coal_req;
        struct tlv_buffer_size                  tlv_buf_size;
 };
 
@@ -487,6 +546,7 @@ union pfvf_tlvs {
        struct tlv_buffer_size                  tlv_buf_size;
        struct pfvf_start_queue_resp_tlv        queue_start;
        struct pfvf_update_tunn_param_tlv       tunn_param_resp;
+       struct pfvf_read_coal_resp_tlv          read_coal_resp;
 };
 
 /* This is a structure which is allocated in the VF, which the PF may update
@@ -605,6 +665,8 @@ enum {
        CHANNEL_TLV_VPORT_UPDATE_SGE_TPA,
        CHANNEL_TLV_UPDATE_TUNN_PARAM,
        CHANNEL_TLV_COALESCE_UPDATE,
+       CHANNEL_TLV_QID,
+       CHANNEL_TLV_COALESCE_READ,
        CHANNEL_TLV_MAX,
 
        /* Required for iterating over vport-update tlvs.