On 3/23/2017 1:03 AM, Ed Czeck wrote:

* Core TX packet moving functions
* Flesh out ark_adapter struct to support TX code
(not all fields used at this patch

Signed-off-by: Ed Czeck <redacted>

<...>

+int
+ark_get_port_id(struct rte_eth_dev *dev, struct ark_adapter *ark)
+{
+	int n = ark->num_ports;
+	int i;
+
+	/* There has to be a smarter way to do this ... */
+	for (i = 0; i < n; i++) {
+		if (ark->port[i].eth_dev == dev)
+			return i;
+	}

Is this function to get dev->data->port_id ?

"struct ark_adapter" is private date per eth_dev, it is possible to keep
port_id per ark, no need to keep whole array on each ark, if I am now
missing anything ...

+	ARK_DEBUG_TRACE("ARK: Device is NOT associated with a port !!");
+	return -1;
+}
+

<...>

+
+#ifdef RTE_LIBRTE_ARK_PAD_TX
+#define ARK_TX_PAD_TO_60   1

Why not using RTE_LIBRTE_ARK_PAD_TX directly, but creating another macro?

+#else
+#define ARK_TX_PAD_TO_60   0
+#endif
+
+
+#ifdef RTE_LIBRTE_ARK_DEBUG_TX
+#define ARK_TX_DEBUG       1
+#define ARK_TX_DEBUG_JUMBO 1

Is it possible to handle RTE_LIBRTE_ARK_DEBUG_TX in log.h file to create
a ..LOG_TX macro and use it, instead of dealing here with new macros?

+#else
+#define ARK_TX_DEBUG       0
+#define ARK_TX_DEBUG_JUMBO 0
+#endif

<...>

+
+#include <stdint.h>
+
+/* Forward declarations */
+struct rte_mbuf;
+struct rte_eth_dev;
+struct rte_eth_stats;
+struct rte_eth_txconf;

Why not include relevant headers, instead of these struct declarations.

<...>