Re: [patch net-next v2 07/12] mlxsw: spectrum: Add the multicast routing offloading logic

On 09/25/2017 04:48 AM, Yunsheng Lin wrote: > Hi, Jiri > > On 2017/9/25 1:22, Jiri Pirko wrote: >> From: Yotam Gigi >> >> Add the multicast router offloading logic, which is in charge of handling >> the VIF and MFC notifications and translating it to the hardware logic API.

Re: [patch net-next v2 06/12] net: mroute: Check if rule is a default rule

On 09/25/2017 04:28 AM, Yunsheng Lin wrote: > Hi, Jiri > > On 2017/9/25 1:22, Jiri Pirko wrote: >> From: Yotam Gigi >> >> When the ipmr starts, it adds one default FIB rule that matches all packets >> and sends them to the DEFAULT (multicast) FIB table. A more complex rule >>

Re: [patch net-next v2 03/12] ipmr: Add FIB notification access functions

On 09/25/2017 04:19 AM, Yunsheng Lin wrote: > Hi, Jiri > > On 2017/9/25 1:22, Jiri Pirko wrote: >> From: Yotam Gigi >> >> Make the ipmr module register as a FIB notifier. To do that, implement both >> the ipmr_seq_read and ipmr_dump ops. >> >> The ipmr_seq_read op returns a

Re: [PATCH net-next] sch_netem: faster rb tree removal

On Sun, 2017-09-24 at 20:05 -0600, David Ahern wrote: > On 9/24/17 7:57 PM, David Ahern wrote: > > Hi Eric: > > > > I'm guessing the cost is in the rb_first and rb_next computations. Did > > you consider something like this: > > > > struct rb_root *root > > struct rb_node **p =

Re: [PATCH] mac80211: aead api to reduce redundancy

On Mon, 2017-09-25 at 12:56 +0800, Herbert Xu wrote: > On Sun, Sep 24, 2017 at 07:42:46PM +0200, Johannes Berg wrote: > > > > Unrelated to this, I'm not sure whose tree this should go through - > > probably Herbert's (or DaveM's with his ACK? not sure if there's a > > crypto tree?) or so? > >

Re: [PATCH] mac80211: aead api to reduce redundancy

On Sun, Sep 24, 2017 at 07:42:46PM +0200, Johannes Berg wrote: > > Unrelated to this, I'm not sure whose tree this should go through - > probably Herbert's (or DaveM's with his ACK? not sure if there's a > crypto tree?) or so? Since you're just rearranging code invoking the crypto API, rather

Re: [PATCH v4 1/9] brcmsmac: make some local variables 'static const' to reduce stack size

Arnd Bergmann writes: > With KASAN and a couple of other patches applied, this driver is one > of the few remaining ones that actually use more than 2048 bytes of > kernel stack: > > broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_gainctrl': >

Re: usb/wireless/rsi_91x: use-after-free write in __run_timers

Andrey Konovalov writes: > I've got the following report while fuzzing the kernel with syzkaller. > > On commit 6e80ecdddf4ea6f3cd84e83720f3d852e6624a68 (Sep 21). > > == > BUG: KASAN: use-after-free in

Re: [PATCH] brcm80211: make const array ucode_ofdm_rates static, reduces object code size

Arend van Spriel writes: > Please use 'brcmsmac:' as prefix instead of 'brcm80211:'. I can fix that. -- Kalle Valo

[PATCH v3 net-next 10/12] gtp: Experimental encapsulation of IPv6 packets

Allow IPv6 mobile subscriber packets. This entails adding an IPv6 mobile subscriber address to pdp context and IPv6 specific variants to find pdp contexts by address. Note that this is experimental support of IPv6, more work is necessary to make this compliant with 3GPP standard. Signed-off-by:

[PATCH v3 net-next 09/12] gtp: Eliminate pktinfo and add port configuration

The gtp pktinfo structure is unnecessary and needs a lot of code to manage it. Remove it. Also, add per pdp port configuration for transmit. Signed-off-by: Tom Herbert --- drivers/net/gtp.c| 177 +--

[PATCH v3 net-next 07/12] gtp: udp recv clean up

Create separate UDP receive functions for GTP version 0 and version 1. Set encap_rcv appropriately when configuring a socket. Signed-off-by: Tom Herbert --- drivers/net/gtp.c | 100 ++ 1 file changed, 49 insertions(+), 51

[PATCH v3 net-next 11/12] gtp: Experimental support encpasulating over IPv6

Allows using GTP datapath over IPv6. Remote peers are indicated by IPv6. Note this is experimental, more work is needed to make this compliant with 3GPP standard. Signed-off-by: Tom Herbert --- drivers/net/gtp.c| 248 ++-

[PATCH v3 net-next 12/12] gtp: Allow configuring GTP interface as standalone

Add new configuration of GTP interfaces that allow specifying a port to listen on (as opposed to having to get sockets from a userspace control plane). This allows GTP interfaces to be configured and the data path tested without requiring a GTP-C daemon. Signed-off-by: Tom Herbert

[PATCH v3 net-next 05/12] gtp: Change to use gro_cells

Call gro_cells_receive instead of netif_rx. Signed-off-by: Tom Herbert --- drivers/net/gtp.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 6dabd605607c..f2aac5d01143 100644 --- a/drivers/net/gtp.c

[PATCH v3 net-next 04/12] iptunnel: Generalize tunnel update pmtu

Add __iptunnel_update_pmtu exported function which does not take an iptunnel argument but instead includes the fields from the iptunnel structure as arguments which are needed in the function. iptunnel_update_pmtu was modified to call __iptunnel_update_pmtu. Signed-off-by: Tom Herbert

[PATCH v3 net-next 08/12] gtp: Call function to update path mtu

Replace mtu handling with call to __iptunnel_update_pmtu. Signed-off-by: Tom Herbert --- drivers/net/gtp.c | 36 ++-- 1 file changed, 6 insertions(+), 30 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index

[PATCH v3 net-next 06/12] gtp: Use goto for exceptions in gtp_udp_encap_recv funcs

Consolidate return logic to make it easier to extend. Signed-off-by: Tom Herbert --- drivers/net/gtp.c | 26 +- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index f2aac5d01143..00e5ea5cb935

[PATCH v3 net-next 00/12] gtp: Additional feature support - Part I

This patch set builds upon the initial GTP implementation to make support closer to that enjoyed by other encapsulation protocols. The major items are: - Experimental IPv6 support - Configurable networking interfaces so that GTP kernel can be used and tested without needing GSN network

[PATCH v3 net-next 02/12] vxlan: Call common functions to get tunnel routes

Call ip_tunnel_get_route and ip6_tnl_get_route to handle getting a route and dealing with the dst_cache. Signed-off-by: Tom Herbert --- drivers/net/vxlan.c | 84 - 1 file changed, 5 insertions(+), 79 deletions(-) diff

[PATCH v3 net-next 01/12] iptunnel: Add common functions to get a tunnel route

ip_tunnel_get_route and ip6_tnl_get_route are created to return routes for a tunnel. These functions are derived from the VXLAN functions. Signed-off-by: Tom Herbert --- include/net/ip6_tunnel.h | 35 +++ include/net/ip_tunnels.h | 33

[PATCH v3 net-next 03/12] gtp: Call common functions to get tunnel routes and add dst_cache

Call ip_tunnel_get_route and dst_cache to pdp context which should improve performance by obviating the need to perform a route lookup on every packet. Signed-off-by: Tom Herbert --- drivers/net/gtp.c | 62 +++ 1 file

Re: [PATCH net-next] sch_netem: faster rb tree removal

On 9/24/17 7:57 PM, David Ahern wrote: > On 9/23/17 12:07 PM, Eric Dumazet wrote: >> From: Eric Dumazet >> >> While running TCP tests involving netem storing millions of packets, >> I had the idea to speed up tfifo_reset() and did experiments. >> >> I tried the

Re: [PATCH net-next RFC 2/5] vhost: introduce helper to prefetch desc index

On 2017年09月22日 17:02, Stefan Hajnoczi wrote: On Fri, Sep 22, 2017 at 04:02:32PM +0800, Jason Wang wrote: diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index f87ec75..8424166d 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -2437,6 +2437,61 @@ struct

Re: [PATCH net-next RFC 1/5] vhost: split out ring head fetching logic

On 2017年09月22日 16:31, Stefan Hajnoczi wrote: On Fri, Sep 22, 2017 at 04:02:31PM +0800, Jason Wang wrote: +/* This looks in the virtqueue and for the first available buffer, and converts + * it to an iovec for convenient access. Since descriptors consist of some + * number of output then some

Re: [PATCH net-next] sch_netem: faster rb tree removal

On 9/23/17 12:07 PM, Eric Dumazet wrote: > From: Eric Dumazet > > While running TCP tests involving netem storing millions of packets, > I had the idea to speed up tfifo_reset() and did experiments. > > I tried the rbtree_postorder_for_each_entry_safe() method that is >

Re: [patch net-next v2 07/12] mlxsw: spectrum: Add the multicast routing offloading logic

Hi, Jiri On 2017/9/25 1:22, Jiri Pirko wrote: > From: Yotam Gigi > > Add the multicast router offloading logic, which is in charge of handling > the VIF and MFC notifications and translating it to the hardware logic API. > > The offloading logic has to overcome several

Re: [patch net-next v2 06/12] net: mroute: Check if rule is a default rule

Hi, Jiri On 2017/9/25 1:22, Jiri Pirko wrote: > From: Yotam Gigi > > When the ipmr starts, it adds one default FIB rule that matches all packets > and sends them to the DEFAULT (multicast) FIB table. A more complex rule > can be added by user to specify that for a specific

Re: [patch net-next v2 03/12] ipmr: Add FIB notification access functions

Hi, Jiri On 2017/9/25 1:22, Jiri Pirko wrote: > From: Yotam Gigi > > Make the ipmr module register as a FIB notifier. To do that, implement both > the ipmr_seq_read and ipmr_dump ops. > > The ipmr_seq_read op returns a sequence counter that is incremented on > every

Re: [PATCH net-next 10/10] net: hns3: Add mqprio support when interacting with network stack

Hi, Jiri On 2017/9/24 19:37, Jiri Pirko wrote: > Sat, Sep 23, 2017 at 02:47:20AM CEST, linyunsh...@huawei.com wrote: >> Hi, Jiri >> >> On 2017/9/23 0:03, Jiri Pirko wrote: >>> Fri, Sep 22, 2017 at 04:11:51PM CEST, linyunsh...@huawei.com wrote: Hi, Jiri >> - if (!tc) { >> + if

[PATCH net-next 0/6] BPF metadata for direct access

This work enables generic transfer of metadata from XDP into skb, meaning the packet has a flexible and programmable room for meta data, which can later be used by BPF to set various skb members when passing up the stack. For details, please see second patch. Support has been implemented and

[PATCH net-next 4/6] bpf: improve selftests and add tests for meta pointer

Add various test_verifier selftests, and a simple xdp/tc functional test that is being attached to veths. Also let new versions of clang use the recently added -mcpu=probe support [1] for the BPF target, so that it can probe the underlying kernel for BPF insn set extensions. We could also just set

[PATCH net-next 2/6] bpf: add meta pointer for direct access

This work enables generic transfer of metadata from XDP into skb. The basic idea is that we can make use of the fact that the resulting skb must be linear and already comes with a larger headroom for supporting bpf_xdp_adjust_head(), which mangles xdp->data. Here, we base our work on a similar

[PATCH net-next 5/6] bpf, nfp: add meta data support

Implement support for transferring XDP meta data into skb for nfp driver; before calling into the program, xdp.data_meta points to xdp.data, where on program return with pass verdict, we call into skb_metadata_set(). Signed-off-by: Daniel Borkmann Acked-by: Alexei

[PATCH net-next 6/6] bpf, ixgbe: add meta data support

Implement support for transferring XDP meta data into skb for ixgbe driver; before calling into the program, xdp.data_meta points to xdp.data, where on program return with pass verdict, we call into skb_metadata_set(). We implement this for the default ixgbe_build_skb() variant. For the

[PATCH net-next 3/6] bpf: update bpf.h uapi header for tools

Looks like a couple of updates missed to get carried into tools/include/uapi/, so copy the bpf.h header as usual to pull in latest updates. Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Acked-by: John Fastabend ---

[PATCH net-next 1/6] bpf: rename bpf_compute_data_end into bpf_compute_data_pointers

Just do the rename into bpf_compute_data_pointers() as we'll add one more pointer here to recompute. Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Acked-by: John Fastabend --- include/linux/filter.h | 9 ++---

Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of unicast traffic

Den 23. sep. 2017 16:31, skrev Andrew Lunn: The point is: Once both external ports are in "forwarding", I see no way to prevent traffic flowing directly between the external ports. Generally, there are port vectors. Port X can send frames only to Port Y. If you don't have that, there are

Re: [PATCH] vxge: Fix rts_mac_en config parameter check

On 24/09/17 19:50:21 +0100, Christos Gkekas wrote: > Current checks return VXGE_HW_BADCFG_RTS_MAC_EN if rts_mac_en is not > equal to DISABLE *and* not equal to ENABLE. This condition is always > false and the check should change to *or* to properly verify the value. > > Signed-off-by: Christos

[PATCH] vxge: Fix rts_mac_en config parameter check

Current checks return VXGE_HW_BADCFG_RTS_MAC_EN if rts_mac_en is not equal to DISABLE *and* not equal to ENABLE. This condition is always false and the check should change to *or* to properly verify the value. Signed-off-by: Christos Gkekas ---

Re: [PATCH] mac80211: aead api to reduce redundancy

2017-09-24 13:42 GMT-04:00 Johannes Berg : > On Sun, 2017-09-24 at 13:21 -0400, Xiang Gao wrote: >> >> Do you mean to put more characters each line in the description >> > Huh, sorry, no - my bad. I was thinking of the code, not the > description at all. Oh yes, these

Re: [PATCH] mac80211: aead api to reduce redundancy

On Sun, 2017-09-24 at 13:21 -0400, Xiang Gao wrote: > > Do you mean to put more characters each line in the description > Huh, sorry, no - my bad. I was thinking of the code, not the description at all. For example here: > -int ieee80211_aes_gcm_encrypt(struct crypto_aead *tfm, u8 *j_0, u8

[patch net-next v2 03/12] ipmr: Add FIB notification access functions

From: Yotam Gigi Make the ipmr module register as a FIB notifier. To do that, implement both the ipmr_seq_read and ipmr_dump ops. The ipmr_seq_read op returns a sequence counter that is incremented on every notification related operation done by the ipmr. To implement that,

Re: [PATCH] mac80211: aead api to reduce redundancy

2017-09-24 11:05 GMT-04:00 Johannes Berg : > On Sun, 2017-09-24 at 01:40 -0400, Xiang Gao wrote: >> Currently, the aes_ccm.c and aes_gcm.c are almost line by line >> copy of each other. This patch reduce code redundancy by moving >> the code in these two files to

[patch net-next v2 05/12] net: ipmr: Add MFC offload indication

From: Yotam Gigi Allow drivers, registered to the fib notification chain indicate whether a multicast MFC route is offloaded or not, similarly to unicast routes. The indication of whether a route is offloaded is done using the mfc_flags field on an mfc_cache struct, and the

[patch net-next v2 02/12] ipmr: Add reference count to MFC entries

From: Yotam Gigi Next commits will introduce MFC notifications through the atomic fib_notification chain, thus allowing modules to be aware of MFC entries. Due to the fact that modules may need to hold a reference to an MFC entry, add reference count to MFC entries to

[patch net-next v2 01/12] fib: notifier: Add VIF add and delete event types

From: Yotam Gigi In order for an interface to forward packets according to the kernel multicast routing table, it must be configured with a VIF index according to the mroute user API. The VIF index is then used to refer to that interface in the mroute user API, for example,

[patch net-next v2 06/12] net: mroute: Check if rule is a default rule

From: Yotam Gigi When the ipmr starts, it adds one default FIB rule that matches all packets and sends them to the DEFAULT (multicast) FIB table. A more complex rule can be added by user to specify that for a specific interface, a packet should be look up at either an

[patch net-next v2 04/12] ipmr: Send FIB notifications on MFC and VIF entries

From: Yotam Gigi Use the newly introduced notification chain to send events upon VIF and MFC addition and deletion. The MFC notifications are sent only on resolved MFC entries, as unresolved cannot be offloaded. Signed-off-by: Yotam Gigi Reviewed-by:

[patch net-next v2 12/12] mlxsw: spectrum: router: Don't ignore IPMR notifications

From: Yotam Gigi Make the Spectrum router logic not ignore the RTNL_FAMILY_IPMR FIB notifications. Past commits added the IPMR VIF and MFC add/del notifications via the fib_notifier chain. In addition, a code for handling these notifications in the Spectrum router logic was

[patch net-next v2 08/12] mlxsw: spectrum: Add the multicast routing hardware logic

From: Yotam Gigi Implement the multicast routing hardware API introduced in previous patch for the specific spectrum hardware. The spectrum hardware multicast routes are written using the RMFT2 register and point to an ACL flexible action set. The actions used for multicast

[patch net-next v2 00/12] mlxsw: Add support for offloading IPv4 multicast routes

From: Jiri Pirko This patch-set introduces offloading of the kernel IPv4 multicast router logic in the Spectrum driver. The first patch makes the Spectrum driver ignore FIB notifications that are not of address family IPv4 or IPv6. This is needed in order to prevent crashes

[patch net-next v2 11/12] mlxsw: spectrum: Notify multicast router on RIF MTU changes

From: Yotam Gigi Due to the fact that multicast routes hold the minimum MTU of all the egress RIFs and trap packets that don't meet it, notify the mulitcast router code on RIF MTU changes. Signed-off-by: Yotam Gigi Reviewed-by: Ido Schimmel

[patch net-next v2 09/12] mlxsw: spectrum: router: Squash the default route table to main

From: Yotam Gigi Currently, the mlxsw Spectrum driver offloads only either the RT_TABLE_MAIN FIB table or the VRF tables, so the RT_TABLE_LOCAL table is squashed to the RT_TABLE_MAIN table to allow local routes to be offloaded too. By default, multicast MFC routes which are

[patch net-next v2 07/12] mlxsw: spectrum: Add the multicast routing offloading logic

From: Yotam Gigi Add the multicast router offloading logic, which is in charge of handling the VIF and MFC notifications and translating it to the hardware logic API. The offloading logic has to overcome several obstacles in order to safely comply with the kernel multicast

[patch net-next v2 10/12] mlxsw: spectrum_router: Add multicast routes notification handling functionality

From: Yotam Gigi Add functionality for calling the multicast routing offloading logic upon MFC and VIF add and delete notifications. In addition, call the multicast routing upon RIF addition and deletion events. As the multicast routing offload logic may sleep, the actual

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

> I'm not sure where a "vendor" is involved with the GTP patches so far. I > think we have to draw a distinction between what you expect from > professional, corporate "vendors" with a commercial interest in mind > (such as supporting their hardware) and what you can expect from people > doing

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

Hi Tom, On Sun, Sep 24, 2017 at 08:55:49AM -0700, Tom Herbert wrote: > Do you believe that these patches are not at all on the right track, > that they can't be built upon to get to a standards-compliant > implementation, and that we are going to have to throw all of this and > start from scratch

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

> It's not about "not liking". I'm very happy about contributions, > including (of course) yours. It's about making sure that code we merge > into the kernel GTP driver will actually be usable to create a > standards-compliant GTP application or not. > Harald, Do you believe that these patches

Re: [RFC] endianness issues in drivers/net/ethernet/qlogic/qed

On Sun, Sep 24, 2017 at 02:34:19PM +, Tayar, Tomer wrote: > > > "qed: Utilize FW 8.10.3.0" has attempted some endianness annotations > > in that driver; unfortunately, either annotations are BS or the driver is > > genuinely > > broken on big-endian hosts. > [...] > > Is that driver

[PATCH] isdn/eicon: do integrity check on cmd->adapter == a->controller early

In my understanding, the reason to have the check on if (cmd->adapter != a->controller) {report error} is to prevent the case where after xdi_copy_from_user() in diva_xdi_write(), data->adapter is changed from what is previously fetched in diva_xdi_open_adapter(), and hence, leading to using a

[PATCH] net/tls: move version check after second userspace fetch

Even the userspace buffer optval passed the version check (i.e., tmp_crypto_info.version == TLS_1_2_VERSION) after the first fetch, it can still be changed before the second copy_from_user() and hence, a version different than TLS_1_2_VERSION may be copied into crypto_info. This patch moves the

Re: [PATCH] mac80211: aead api to reduce redundancy

On Sun, 2017-09-24 at 01:40 -0400, Xiang Gao wrote: > Currently, the aes_ccm.c and aes_gcm.c are almost line by line > copy of each other. This patch reduce code redundancy by moving > the code in these two files to crypto/aead_api.c to make it a > higher level aead api. The aes_ccm.c and

RE: [RFC] endianness issues in drivers/net/ethernet/qlogic/qed

> "qed: Utilize FW 8.10.3.0" has attempted some endianness annotations > in that driver; unfortunately, either annotations are BS or the driver is > genuinely > broken on big-endian hosts. [...] > Is that driver intended to be used on big-endian hosts at all? Thanks for taking the time to

Re: [RESEND] Re: usb/net/p54: trying to register non-static key in p54_unregister_leds

On Sat, 2017-09-23 at 21:37 +0200, Christian Lamparter wrote: > But this also begs the question: Is this really working then? > From what I can tell, if CONFIG_LOCKDEP is not set then there's no > BUG no WARN, no other splat or any other odd system behaviour. Does > [cancel |

[PATCH] net: bcm63xx_enet: Use setup_timer and mod_timer

Use setup_timer and mod_timer API instead of structure assignments. This is done using Coccinelle and semantic patch used for this as follows: @@ expression x,y,z,a,b; @@ -init_timer (); +setup_timer (, y, z); +mod_timer (, b); -x.function = y; -x.data = z; -x.expires = b; -add_timer();

Re: [PATCH net-next 10/10] net: hns3: Add mqprio support when interacting with network stack

Sat, Sep 23, 2017 at 02:47:20AM CEST, linyunsh...@huawei.com wrote: >Hi, Jiri > >On 2017/9/23 0:03, Jiri Pirko wrote: >> Fri, Sep 22, 2017 at 04:11:51PM CEST, linyunsh...@huawei.com wrote: >>> Hi, Jiri >>> > - if (!tc) { > + if (if_running) { > + (void)hns3_nic_net_stop(netdev); >

Re: [PATCH v2 net-next 3/4] qed: Fix maximum number of CQs for iWARP

On Sun, Sep 24, 2017 at 12:09:44PM +0300, Michal Kalderon wrote: > The maximum number of CQs supported is bound to the number > of connections supported, which differs between RoCE and iWARP. > > This fixes a crash that occurred in iWARP when running 1000 sessions > using perftest. > > Fixes:

[PATCH v2 net-next 1/4] qed: Add iWARP enablement support

This patch is the last of the initial iWARP patch series. It adds the possiblity to actually detect iWARP from the device and enable it in the critical locations which basically make iWARP available. It wasn't submitted until now as iWARP hadn't been accepted into the rdma tree. Signed-off-by:

[PATCH v2 net-next 0/4] qed: iWARP fixes and enhancements

This patch series includes several fixes and enhancements related to iWARP. Patch #1 is actually the last of the initial iWARP submission. It has been delayed until now as I wanted to make sure that qedr supports iWARP prior to enabling iWARP device detection. iWARP changes in RDMA tree have

[PATCH v2 net-next 2/4] qed: Add iWARP out of order support

iWARP requires OOO support which is already provided by the ll2 interface (until now was used only for iSCSI offload). The changes mostly include opening a ll2 dedicated connection for OOO and notifiying the FW about the handle id. Signed-off-by: Michal Kalderon

[PATCH v2 net-next 4/4] qed: iWARP - Add check for errors on a SYN packet

A SYN packet which arrives with errors from FW should be dropped. This required adding an additional field to the ll2 rx completion data. Signed-off-by: Michal Kalderon Signed-off-by: Ariel Elior ---

[PATCH v2 net-next 3/4] qed: Fix maximum number of CQs for iWARP

The maximum number of CQs supported is bound to the number of connections supported, which differs between RoCE and iWARP. This fixes a crash that occurred in iWARP when running 1000 sessions using perftest. Fixes: 67b40dccc45 ("qed: Implement iWARP initialization, teardown and qp operations")