Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 156
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 29 12月, 2016 1 次提交
  3. 14 12月, 2016 1 次提交
  5. 19 11月, 2016 3 次提交
  7. 30 10月, 2016 2 次提交
  9. 09 9月, 2016 1 次提交
  11. 18 8月, 2016 4 次提交
  13. 17 8月, 2016 3 次提交
  15. 14 8月, 2016 2 次提交
  17. 26 7月, 2016 1 次提交
  19. 15 7月, 2016 1 次提交
  21. 10 6月, 2016 3 次提交
  23. 17 5月, 2016 2 次提交
  25. 13 5月, 2016 2 次提交
  27. 16 4月, 2016 2 次提交
  29. 22 3月, 2016 2 次提交
  31. 10 3月, 2016 1 次提交
    • M
      net/mlx5_core: Introduce forward to next priority action · b3638e1a
      由 Maor Gottlieb 提交于 
      Add support to create flow rule that forward packets
to the first flow table in the next priority (next priority
could be the first priority in the next namespace or the
next priority in the same namespace).
This feature could be used for DONT_TRAP rules or rules
that only want to mark the packet with flow tag.

In order to do it optimally, each flow table has list
of all rules that point to this flow table,
when a flow table is destroyed/created, we update the list
head correspondingly.

This kind of rule is created when destination is NULL and
action is MLX5_FLOW_CONTEXT_ACTION_FWD_NEXT_PRIO.
Signed-off-by: NMaor Gottlieb <maorg@mellanox.com>
Reviewed-by: NMatan Barak <matanb@mellanox.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>
      b3638e1a
  33. 03 3月, 2016 1 次提交
  35. 02 3月, 2016 2 次提交
  37. 01 3月, 2016 3 次提交
  39. 25 2月, 2016 2 次提交
  41. 17 2月, 2016 1 次提交
    • M
      net/mlx5: Use offset based reserved field names in the IFC header file · b4ff3a36
      由 Matan Barak 提交于 
      mlx5_ifc.h is a header file representing the API and ABI between
the driver to the firmware and hardware. This file is used from
both the mlx5_ib and mlx5_core drivers.

Previously, this file used incrementing counter to indicate
reserved fields, for example:

struct mlx5_ifc_odp_per_transport_service_cap_bits {
        u8         send[0x1];
        u8         receive[0x1];
        u8         write[0x1];
        u8         read[0x1];
        u8         reserved_0[0x1];
        u8         srq_receive[0x1];
        u8         reserved_1[0x1a];
};

If one developer implements through net-next feature A that uses
reserved_0, they replace it with featureA and renames reserved_1 to
reserved_0. In the same kernel cycle, a 2nd developer could implement
feature B through the rdma tree, that uses reserved_1 and split it to
featureB and a smaller reserved_1 field. This will cause a conflict
when the two trees are merged.

The source of this conflict is that the 1st developer changed *all*
reserved fields.

As Linus suggested, we change the layout of structs to:

struct mlx5_ifc_odp_per_transport_service_cap_bits {
	u8         send[0x1];
	u8         receive[0x1];
	u8         write[0x1];
	u8         read[0x1];
	u8         reserved_at_4[0x1];
	u8         srq_receive[0x1];
	u8         reserved_at_6[0x1a];
};

This makes the conflicts much more rare and preserves the locality of
changes.
Signed-off-by: NMatan Barak <matanb@mellanox.com>
Signed-off-by: NAlaa Hleihel <alaa@mellanox.com>
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4ff3a36