lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1354533781-31575-1-git-send-email-vipul@chelsio.com>
Date:	Mon,  3 Dec 2012 16:52:56 +0530
From:	Vipul Pandya <vipul@...lsio.com>
To:	linux-rdma@...r.kernel.org, netdev@...r.kernel.org
Cc:	roland@...estorage.com, davem@...emloft.net, divy@...lsio.com,
	dm@...lsio.com, kumaras@...lsio.com, swise@...ngridcomputing.com,
	abhishek@...lsio.com, Vipul Pandya <vipul@...lsio.com>
Subject: [PATCH V3 0/5] Add LE hash collision bug fix for active and passive offloaded connections

This patch series fixes the LE hash collision issue in cxgb4 and RDMA/cxgb4
drivers in kernel.org.

If the hash functionality is enabled in T4 then tuple information of active and
passive offloaded connections are stored in DDR3 memory. LE (Lookup Engine)
implements the interface to search this tuple entries using hash algorithm. To
avoid LE hash collision, firmware provides new mechanisms to setup active and
passive open connections.

In case of active open connection, firmware detects LE hash collision situation
and notifies driver. Driver uses fw_ofld_connection work request to offload
that connection. Its tuple information will be stored in TCAM memory array. 

In case of passive open connection, server filter region is created in TCAM.
This region stores the filter which will redirect the incoming SYN packet to
offload queues. After this driver tries to establish the connection using
firmware work request.

This patch series also adds framework for managing filters and to use T4's
filter capabilities.

Following testing has been carried out successfully on this patch series.
1. 1000 active open connections created and saw that tcam_full counter is
getting incremented through debugfs file.
2. Multiple passive open connections were created and ran the same test
repetatively to verify server filter is getting created and deleted properly.

The patch-series is based on Roland's infiniband tree (for-next branch),
and involves changes on cxgb4 and RDMA/cxgb4 drivers. Both linux-rdma and netdev
are included in this post for review.

We have some more bug fixes in RDMA/cxgb4 after this patch series. So, we would
like to request this series to get mereged through Roland's infiniband for-next
tree.

V2: Changed commenting style from kernel-doc format('/**') to normal
V3: Resending the whole patch series again with the missing patches in V2

Thanks,
Vipul Pandya

Vipul Pandya (5):
  cxgb4: Add T4 filter support
  cxgb4: Add LE hash collision bug fix path in LLD driver
  RDMA/cxgb4: Fix LE hash collision bug for active open connection
  RDMA/cxgb4: Fix LE hash collision bug for passive open connection
  RDMA/cxgb4: Fix bug for active and passive LE hash collision path

 drivers/infiniband/hw/cxgb4/cm.c                |  789 +++++++++++++++++++---
 drivers/infiniband/hw/cxgb4/device.c            |  210 ++++++-
 drivers/infiniband/hw/cxgb4/iw_cxgb4.h          |   33 +
 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h      |  146 +++++
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c |  473 +++++++++++++-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h  |   23 +-
 drivers/net/ethernet/chelsio/cxgb4/l2t.c        |   34 +
 drivers/net/ethernet/chelsio/cxgb4/l2t.h        |    3 +
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c      |   23 +-
 drivers/net/ethernet/chelsio/cxgb4/t4_msg.h     |   66 ++
 drivers/net/ethernet/chelsio/cxgb4/t4_regs.h    |   37 ++
 drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h   |  388 +++++++++++
 12 files changed, 2100 insertions(+), 125 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ