Differential D32551 Diff 103830 sys/dev/mlx5/mlx5_en/en.h

Changeset View

Standalone View

sys/dev/mlx5/mlx5_en/en.h

Show First 20 Lines • Show All 1,143 Lines • ▼ Show 20 Lines	#define PRIV_ASSERT_LOCKED(priv) sx_assert(&(priv)->state_lock, SA_XLOCKED)
int clbr_curr;		int clbr_curr;
struct mlx5e_clbr_point clbr_points[2];		struct mlx5e_clbr_point clbr_points[2];
u_int clbr_gen;		u_int clbr_gen;

struct mlx5e_dcbx dcbx;		struct mlx5e_dcbx dcbx;
bool sw_is_port_buf_owner;		bool sw_is_port_buf_owner;

struct pfil_head *pfil;		struct pfil_head *pfil;

		bool ifcap_rxtls4 : 1;
		hselaskyUnsubmitted Done Inline Actions These fields seem like boiler-plate code that should be factored into some kind of generic structure? Also the code that interact with them seems boilerplate! hselasky: These fields seem like boiler-plate code that should be factored into some kind of generic…
		kibAuthorUnsubmitted Done Inline Actions It is because the driver implements all that capabilities. If we plan to grow the caps, providing the structure means that we cannot keep KBI for drivers, which is nicely side-stepped by nvlist approach. In fact, some of the features explicitly handled by the booleans there, could eventually deduced from other data in the priv/other internal structures. For instance, ifcap_lro probably could be subsumed by params.hw_lro_en. I do not to change the driver logic during the conversion, but eventually this list probably become thinner. kib: It is because the driver implements all that capabilities. If we plan to grow the caps…
		bool ifcap_rxtls6 : 1;

struct mlx5e_channel channel[];		struct mlx5e_channel channel[];
};		};

#define MLX5E_NET_IP_ALIGN 2		#define MLX5E_NET_IP_ALIGN 2

struct mlx5e_tx_wqe {		struct mlx5e_tx_wqe {
struct mlx5_wqe_ctrl_seg ctrl;		struct mlx5_wqe_ctrl_seg ctrl;
struct mlx5_wqe_eth_seg eth;		struct mlx5_wqe_eth_seg eth;
▲ Show 20 Lines • Show All 154 Lines • Show Last 20 Lines