On 1/21/2016 12:57 AM, Steve Wise wrote:
I also asked you why the port mapper code has to be present in each
iwarp driver and not part of the IB core stack, and you responded
"i40iw iwarp driver registers with port mapper and uses its services.
Beside that it is not the scope of the patch series"
On 2016/1/21 13:13, Michael S. Tsirkin wrote:
On Thu, Jan 21, 2016 at 10:11:35AM +0800, Yang Zhang wrote:
On 2016/1/20 22:35, Michael S. Tsirkin wrote:
On Tue, Dec 01, 2015 at 02:39:45PM +0800, Jason Wang wrote:
This patch tries to poll for new added tx buffer or socket receive
queue for a whi
On January 20, 2016 6:58:09 PM PST, David Miller wrote:
>From:
>Date: Thu, 21 Jan 2016 00:59:42 +
>
>> > I'm experiencing misbehavior after restart system.
>>> Can you wait applying the patch?
>>>
>>> Sorry about it.
>>> Woojung
>>
>> Sorry for spam. Version mismatch happened. :(
>> It wor
Remove unnecessory "if" statement and club it with previos "if" block.
Signed-off-by: Sunil Shahu
---
net/mac80211/mesh_plink.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index bd3d55e..e5851ae 100644
--- a/n
In a bonding setting, we determines fragment size according to MTU and
PMTU associated to the bonding master. If the slave finds the fragment
size is too big, it drops the fragment and calls ip_rt_update_pmtu(),
passing _skb_ and _pmtu_, trying to update the path MTU.
Problem is that the target dev
在 2016年01月21日 12:05, Jay Vosburgh 写道:
Wengang Wang wrote:
[...]
For ipip, yes seems update_pmtu is called in line for each call of
queue_xmit. Do you know if it's a good configuration for ipip + bonding?
Yes, it is.
Other's comment and suggestion?
I agree with Sabrina Du
On Thu, Jan 21, 2016 at 10:11:35AM +0800, Yang Zhang wrote:
> On 2016/1/20 22:35, Michael S. Tsirkin wrote:
> >On Tue, Dec 01, 2015 at 02:39:45PM +0800, Jason Wang wrote:
> >>This patch tries to poll for new added tx buffer or socket receive
> >>queue for a while at the end of tx/rx processing. The
在 2016年01月20日 23:18, Sabrina Dubroca 写道:
2016-01-20, 13:32:13 +0800, Wengang Wang wrote:
In a bonding setting, we determines fragment size according to MTU and
PMTU associated to the bonding master. If the slave finds the fragment
size is too big, it drops the fragment and calls ip_rt_update_p
From: David Miller
Date: Tue, 19 Jan 2016 14:36:28 -0500
>
> From: Julia Lawall
> Date: Tue, 19 Jan 2016 19:54:20 +0100 (CET)
[...]
> > I just wondered. I was looking at dependencies between networking files.
> > This one stands out because nothing is dependenton it, even the files it
> > is c
The defconfig build of blackfin is failing with the error:
arch/blackfin/include/asm/bfin_serial.h:269:0: warning: "port_membase" redefined
drivers/net/irda/bfin_sir.h:85:0: note: this is the location of the previous
definition
arch/blackfin/include/asm/bfin_serial.h:382:0: warning: "get_lsr_cach
On Wed, 2016-01-20 at 20:36 -0800, Eric Dumazet wrote:
> On Wed, 2016-01-20 at 17:16 +0530, skallam wrote:
> > From: Siva Reddy Kallam
> >
> > There is an issue on the GSO path inside tg3_tso_bug() when we don't
> > have sufficient descriptors available, we stop the queue. This queue
> > may nev
On Wed, 2016-01-20 at 17:16 +0530, skallam wrote:
> From: Siva Reddy Kallam
>
> There is an issue on the GSO path inside tg3_tso_bug() when we don't
> have sufficient descriptors available, we stop the queue. This queue
> may never get started again as there are no Tx completions pending.
>
> Fo
Wengang Wang wrote:
[...]
>For ipip, yes seems update_pmtu is called in line for each call of
>queue_xmit. Do you know if it's a good configuration for ipip + bonding?
Yes, it is.
>Other's comment and suggestion?
I agree with Sabrina Dubroca 's suggestions
from yesterday.
On Wed, 2016-01-20 at 11:08 +0300, Pavel Tikhomirov wrote:
> It seem to be non intentionaly changed to tx in
> commit adc810900a70 ("ixgbe: Refactor busy poll socket code to
> address
> multiple issues")
>
> Lock is taken from ixgbe_low_latency_recv, and there under this
> lock we use ixgbe_clean_
From: skallam
Date: Wed, 20 Jan 2016 17:16:56 +0530
> From: Siva Reddy Kallam
>
> First patch:
> This patch includes additional maintainer for tg3
>
> Second patch:
> Fix for tg3 transmit queue 0 timed out when too many gso_segs
Why are you targetting bug fixes at the 'net-next' t
From:
Date: Thu, 21 Jan 2016 00:59:42 +
> > I'm experiencing misbehavior after restart system.
>> Can you wait applying the patch?
>>
>> Sorry about it.
>> Woojung
>
> Sorry for spam. Version mismatch happened. :(
> It works as expected on USB-to-Ethernet point of view.
So Florian, can I
From: Pablo Neira Ayuso
Date: Wed, 20 Jan 2016 18:03:58 +0100
> The following patchset contains Netfilter fixes for your net tree, they
> are:
>
> 1) Fix accidental 3-times le/be conversion for 64-bits in nft_byteorder,
>from Florian Westphal.
>
> 2) Get rid of defensive cidr = 0 check in t
From: Xin Long
Date: Wed, 20 Jan 2016 16:12:33 +0800
> Documentation should be kept consistent with the code:
>
> static int tcp_syn_retries_max = MAX_TCP_SYNCNT;
> #define MAX_TCP_SYNCNT 127
>
> Signed-off-by: Xin Long
Applied.
On Wed, Jan 20, 2016 at 6:31 PM, Thomas Graf wrote:
> On 01/20/16 at 05:47pm, Jesse Gross wrote:
>> Just to merge the two threads together, all of protocols that would be
>> affected by this also have "normal" GRO handlers that will run when
>> the packet is first received. There's no argument tha
From: Richard Cochran
Date: Wed, 20 Jan 2016 14:25:45 +0100
> On Wed, Jan 20, 2016 at 11:22:28AM +0100, Manfred Rudigier wrote:
>> PHY status frames are not reliable, the PHY may not be able to send them
>> during heavy receive traffic. This overflow condition is signaled by the
>> PHY in the nex
From: Eric Dumazet
Date: Wed, 20 Jan 2016 16:25:01 -0800
> From: Eric Dumazet
>
> Lorenzo reported that we could not properly find v4mapped sockets
> in inet_diag_find_one_icsk(). This patch fixes the issue.
>
> Reported-by: Lorenzo Colitti
> Signed-off-by: Eric Dumazet
Applied, thanks Eric
From: Jesse Gross
Date: Wed, 20 Jan 2016 17:59:49 -0800
> GRO is currently not aware of tunnel metadata generated by lightweight
> tunnels and stored in the dst. This leads to two possible problems:
> * Incorrectly merging two frames that have different metadata.
> * Leaking of allocated metada
On Wed, Jan 20, 2016 at 4:25 PM, Eric Dumazet wrote:
> Lorenzo reported that we could not properly find v4mapped sockets
> in inet_diag_find_one_icsk(). This patch fixes the issue.
>
> Reported-by: Lorenzo Colitti
> Signed-off-by: Eric Dumazet
This fixes the problem for me. I tested that SOCK_D
在 2016年01月20日 17:56, zhuyj 写道:
On 01/20/2016 05:47 PM, Wengang Wang wrote:
在 2016年01月20日 15:54, zhuyj 写道:
On 01/20/2016 03:38 PM, Wengang Wang wrote:
在 2016年01月20日 14:24, zhuyj 写道:
On 01/20/2016 01:32 PM, Wengang Wang wrote:
In a bonding setting, we determines fragment size according to
On 01/20/16 at 05:59pm, Jesse Gross wrote:
> GRO is currently not aware of tunnel metadata generated by lightweight
> tunnels and stored in the dst. This leads to two possible problems:
> * Incorrectly merging two frames that have different metadata.
> * Leaking of allocated metadata from merged
the warning was:
iproute.c:301:12: warning: 'val' may be used uninitialized in this
function [-Wmaybe-uninitialized]
features &= ~RTAX_FEATURE_ECN;
^
iproute.c:575:10: note: 'val' was declared here
__u32 val;
^
Signed-off-by: Zhang Shengju
---
ip/iproute.c | 2 +-
1 f
On 01/20/16 at 05:47pm, Jesse Gross wrote:
> Just to merge the two threads together, all of protocols that would be
> affected by this also have "normal" GRO handlers that will run when
> the packet is first received. There's no argument that that is
> preferable if it is available. However, GRO ce
On 01/20/16 at 04:34pm, Eric Dumazet wrote:
> On Wed, 2016-01-20 at 16:19 -0800, Jesse Gross wrote:
>
> > I have a patch that implements the comparison between dsts. For
> > packets without a dst, there isn't really a cost and if we do have a
> > dst then GRO is still a benefit. So it seems like i
On Wed, 2016-01-20 at 17:47 -0800, Jesse Gross wrote:
> Just to merge the two threads together, all of protocols that would be
> affected by this also have "normal" GRO handlers that will run when
> the packet is first received. There's no argument that that is
> preferable if it is available. How
On 2016/1/20 22:35, Michael S. Tsirkin wrote:
On Tue, Dec 01, 2015 at 02:39:45PM +0800, Jason Wang wrote:
This patch tries to poll for new added tx buffer or socket receive
queue for a while at the end of tx/rx processing. The maximum time
spent on polling were specified through a new kind of vr
On Wed, 2016-01-20 at 17:59 -0800, Jesse Gross wrote:
> GRO is currently not aware of tunnel metadata generated by lightweight
> tunnels and stored in the dst. This leads to two possible problems:
> * Incorrectly merging two frames that have different metadata.
> * Leaking of allocated metadata f
GRO is currently not aware of tunnel metadata generated by lightweight
tunnels and stored in the dst. This leads to two possible problems:
* Incorrectly merging two frames that have different metadata.
* Leaking of allocated metadata from merged frames.
This avoids those problems by comparing th
On Wed, Jan 20, 2016 at 4:48 PM, Eric Dumazet wrote:
> On Wed, 2016-01-20 at 16:27 -0800, Jesse Gross wrote:
>> GRO is currently not aware of tunnel metadata generated by lightweight
>> tunnels and stored in the dst. This leads to two possible problems:
>> * Incorrectly merging two frames that ha
> I'm experiencing misbehavior after restart system.
> Can you wait applying the patch?
>
> Sorry about it.
> Woojung
Sorry for spam. Version mismatch happened. :(
It works as expected on USB-to-Ethernet point of view.
Woojung
On Wed, 2016-01-20 at 16:27 -0800, Jesse Gross wrote:
> GRO is currently not aware of tunnel metadata generated by lightweight
> tunnels and stored in the dst. This leads to two possible problems:
> * Incorrectly merging two frames that have different metadata.
> * Leaking of allocated metadata f
On Wed, 2016-01-20 at 16:19 -0800, Jesse Gross wrote:
> I have a patch that implements the comparison between dsts. For
> packets without a dst, there isn't really a cost and if we do have a
> dst then GRO is still a benefit. So it seems like it is worth doing,
> even if it is more expensive than
GRO is currently not aware of tunnel metadata generated by lightweight
tunnels and stored in the dst. This leads to two possible problems:
* Incorrectly merging two frames that have different metadata.
* Leaking of allocated metadata from merged frames.
This avoids those problems by comparing th
From: Eric Dumazet
Lorenzo reported that we could not properly find v4mapped sockets
in inet_diag_find_one_icsk(). This patch fixes the issue.
Reported-by: Lorenzo Colitti
Signed-off-by: Eric Dumazet
---
net/ipv4/inet_diag.c | 21 ++---
1 file changed, 14 insertions(+), 7 de
When configuring checksums on UDP tunnels, the flags are different
for IPv4 vs. IPv6 (and reversed). However, when lightweight tunnels
are enabled the flags used are always the IPv4 versions, which are
ignored in the IPv6 code paths. This uses the correct IPv6 flags, so
checksums can be controlled
On Wed, Jan 20, 2016 at 4:07 PM, Eric Dumazet wrote:
> On Wed, 2016-01-20 at 16:43 -0700, John wrote:
>>
>> On 01/19/2016 06:31 PM, Thomas Graf wrote:
>> > On 01/19/16 at 04:51pm, Jesse Gross wrote:
>> >> On Tue, Jan 19, 2016 at 4:17 PM, Eric Dumazet
>> >> wrote:
>> >>> So what is the purpose of
On Wed, 2016-01-20 at 16:43 -0700, John wrote:
>
> On 01/19/2016 06:31 PM, Thomas Graf wrote:
> > On 01/19/16 at 04:51pm, Jesse Gross wrote:
> >> On Tue, Jan 19, 2016 at 4:17 PM, Eric Dumazet
> >> wrote:
> >>> So what is the purpose of having a dst if we need to drop it ?
> >>>
> >>> Adding code
On 01/19/2016 06:31 PM, Thomas Graf wrote:
On 01/19/16 at 04:51pm, Jesse Gross wrote:
On Tue, Jan 19, 2016 at 4:17 PM, Eric Dumazet wrote:
So what is the purpose of having a dst if we need to drop it ?
Adding code in GRO would be fine if someone explains me the purpose of
doing apparently u
On Wed, 2016-01-20 at 23:54 +0100, Arnd Bergmann wrote:
> On Wednesday 20 January 2016 14:44:45 Jeff Kirsher wrote:
> > Yeah, I have a fix for that as well.
> >
> > You can confirm by pulling my next-queue tree (dev-queue branch).
> > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-
>
Alexander Duyck wrote:
There isn't any need to add such an indication, nor do we need to
start bitflipping the return value from csum_fold in all cases. I
think there was just some confusion about UDP checksums vs GRE or TCP
checksums.
Yeah. I think I finally got there. The naive software me
On Wed, Jan 20, 2016 at 3:02 PM, Eric Dumazet wrote:
> On Thu, 2016-01-21 at 00:20 +0200, Or Gerlitz wrote:
>
>> Dave, I assume you refer to the RSS hash result which is written by
>> NIC HWs to the completion descriptor and then fed to the stack by the
>> driver calling skb_set_hash(.)? Well, thi
On Sun, Jan 17, 2016 at 12:06:58PM -0500, Dave Jones wrote:
> I've managed to trigger this a few times the last few days, on Linus' tree.
>
> ==
> BUG: KASAN: slab-out-of-bounds in pptp_connect+0xb7b/0xc70 [pptp] at addr
> 8
On Thu, 2016-01-21 at 00:20 +0200, Or Gerlitz wrote:
> Dave, I assume you refer to the RSS hash result which is written by
> NIC HWs to the completion descriptor and then fed to the stack by the
> driver calling skb_set_hash(.)? Well, this can be taken even further.
>
> Suppose a the NIC can be p
> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org
> [mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Or Gerlitz
> Sent: Wednesday, January 20, 2016 4:25 PM
> To: Faisal Latif
> Cc: Doug Ledford; linux-r...@vger.kernel.org; Linux Netdev List; Jeff
> Kirsher; e1000-r...@
On Wednesday 20 January 2016 14:44:45 Jeff Kirsher wrote:
> Yeah, I have a fix for that as well.
>
> You can confirm by pulling my next-queue tree (dev-queue branch).
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git d
> ev-queue
>
I checked out that branch, but still see b
[...]
>
>> pktgen (4 cores) sending ~50Mpps
> [...]
>
> The 20M for single ring/core and 50M pps for four streams are really
> cool results. Do the scripts to get ~such results exist in your
> network testing github repo? last time I looked I wasn't sure if the
> multi-stream case is supported.
On Wed, 2016-01-20 at 23:28 +0100, Arnd Bergmann wrote:
> On Wednesday 20 January 2016 14:17:25 Jeff Kirsher wrote:
> > On Wed, 2016-01-20 at 11:42 +0100, Arnd Bergmann wrote:
> > > The addition of the geneve tunnel offload code left a couple
> > > of functions unconditionally defined but empty whe
On Wed, Jan 20, 2016 at 11:13 AM, Jesper Dangaard Brouer
wrote:
> Hi All,
>
> I wrote a small tool[1] to extract ethtool --statistics|-S, sample and
> present it in a more human readable manor. You might also find this
> useful...
>
> https://github.com/netoptimizer/network-testing/blob/master/bi
On Wednesday 20 January 2016 14:17:25 Jeff Kirsher wrote:
> On Wed, 2016-01-20 at 11:42 +0100, Arnd Bergmann wrote:
> > The addition of the geneve tunnel offload code left a couple
> > of functions unconditionally defined but empty whenever CONFIG_VXLAN
> > and CONFIG_GENEVE are disabled. gcc warns
On Wed, Jan 20, 2016 at 9:40 PM, Faisal Latif wrote:
> Changes since v2:
[...]
> *move netlink patch up
I also asked you why the port mapper code has to be present in each
iwarp driver and not part of the IB core stack, and you responded
"i40iw iwarp driver registers with port ma
On Mon, Jan 18, 2016 at 6:24 PM, David Miller wrote:
> From: Jesper Dangaard Brouer
> Date: Mon, 18 Jan 2016 11:27:03 +0100
>
>> Down in the driver layer (RX), I think it is too early to categorize
>> Related/Unrelated SKB's, because we want to delay touching packet-data
>> as long as possible (w
Florian & David,
I'm experiencing misbehavior after restart system.
Can you wait applying the patch?
Sorry about it.
Woojung
> -Original Message-
> From: Florian Fainelli [mailto:f.faine...@gmail.com]
> Sent: Wednesday, January 20, 2016 4:30 PM
> To: Woojung Huh - C21699; da...@davemloft
On Wed, 2016-01-20 at 11:42 +0100, Arnd Bergmann wrote:
> The addition of the geneve tunnel offload code left a couple
> of functions unconditionally defined but empty whenever CONFIG_VXLAN
> and CONFIG_GENEVE are disabled. gcc warns about this:
>
> i40e_main.c:7049:13: warning: 'i40e_sync_udp_fil
Le 20/01/2016 13:20, woojung@microchip.com a écrit :
>>> Targetting the "net" tree since these are bugfixes, but I would like
>>> Woojun and Andrew to take a look and test that on their respective
>>> HW setups as well.
>>
>> Ok I'll wait for Woojun and Andrew to give feedback.
>
> This patch
> > Targetting the "net" tree since these are bugfixes, but I would like
> > Woojun and Andrew to take a look and test that on their respective
> > HW setups as well.
>
> Ok I'll wait for Woojun and Andrew to give feedback.
This patch fixes periodic phy read_status access when phy is configured a
On Wed, Jan 20, 2016 at 11:58 AM, Tom Herbert wrote:
> On Wed, Jan 20, 2016 at 11:35 AM, Alexander Duyck
> wrote:
>> On Wed, Jan 20, 2016 at 11:11 AM, Rustad, Mark D
>> wrote:
>>> Alexander Duyck wrote:
>>>
Actually you may want to go the other way on that. If they weren't
flipping t
On Wed, Jan 20, 2016 at 11:35 AM, Alexander Duyck
wrote:
> On Wed, Jan 20, 2016 at 11:11 AM, Rustad, Mark D
> wrote:
>> Alexander Duyck wrote:
>>
>>> Actually you may want to go the other way on that. If they weren't
>>> flipping the checksum value for GRE before why should we start doing
>>> t
i40iw_hmc.[ch] are to manage hmc for the device.
Acked-by: Anjali Singhai Jain
Acked-by: Shannon Nelson
Signed-off-by: Faisal Latif
---
drivers/infiniband/hw/i40iw/i40iw_hmc.c | 821
drivers/infiniband/hw/i40iw/i40iw_hmc.h | 241 ++
2 files changed, 106
i40iw_pble.[ch] to manage pble resource for iwarp clients.
Changes since v2:
remove unnecessary casts
Acked-by: Anjali Singhai Jain
Acked-by: Shannon Nelson
Signed-off-by: Faisal Latif
---
drivers/infiniband/hw/i40iw/i40iw_pble.c | 618 +++
drivers/infiniba
header files for hardware accesses
Signed-off-by: Faisal Latif
---
drivers/infiniband/hw/i40iw/i40iw_d.h| 1713 ++
drivers/infiniband/hw/i40iw/i40iw_p.h| 106 ++
drivers/infiniband/hw/i40iw/i40iw_type.h | 1312 +++
3 files changed, 3131 in
i40iw_user.h and i40iw_uk.c are used by both user library as well as
kernel requests.
Acked-by: Anjali Singhai Jain
Acked-by: Shannon Nelson
Signed-off-by: Faisal Latif
---
drivers/infiniband/hw/i40iw/i40iw_uk.c | 1204 ++
drivers/infiniband/hw/i40iw/i40iw_user.h
Kconfig and Makefile needed to build iwarp module.
Changes since v2:
moved from Kbuild to Makefile
Signed-off-by: Faisal Latif
---
drivers/infiniband/hw/i40iw/Kconfig | 7 +++
drivers/infiniband/hw/i40iw/Makefile | 9 +
2 files changed, 16 insertions(+)
create mode 100644
X722 Hardware registers defines for iWARP component.
Acked-by: Anjali Singhai Jain
Acked-by: Shannon Nelson
Signed-off-by: Faisal Latif
---
drivers/infiniband/hw/i40iw/i40iw_register.h | 1030 ++
1 file changed, 1030 insertions(+)
create mode 100644 drivers/infiniband/
i40iw_ctrl.c provides for hardware wqe support and cqp.
Changes since v2:
cleanup coccinelle error reported by Julia Lawall
Changes since v1:
reported by Christoph Hellwig's review
-remove unnecessary casts
Acked-by: Anjali Singhai Jain
Acked-by: Shannon Nelson
Signed-o
MAINTAINERS, Kconfig, and Makefile to build i40iw module
Signed-off-by: Faisal Latif
---
MAINTAINERS| 10 ++
drivers/infiniband/Kconfig | 1 +
drivers/infiniband/hw/Makefile | 1 +
3 files changed, 12 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9
i40iw_puda.[ch] are files to handle iwarp connection packets as
well as exception packets over multiple privilege mode uda queues.
Acked-by: Anjali Singhai Jain
Acked-by: Shannon Nelson
Signed-off-by: Faisal Latif
---
drivers/infiniband/hw/i40iw/i40iw_puda.c | 1436
i40iw_main.c contains routines for i40e <=> i40iw interface and setup.
i40iw.h is header file for main device data structures.
i40iw_status.h is for return status codes.
Changes from v2:
more cast improvement
fixed timing issue during unload
added paramater change call from
i40iw_vf.[ch] and i40iw_virtchnl[ch] are used for virtual
channel support for iWARP VF module.
Changes since v2:
code cleanup
Acked-by: Anjali Singhai Jain
Acked-by: Shannon Nelson
Signed-off-by: Faisal Latif
---
drivers/infiniband/hw/i40iw/i40iw_vf.c | 85 +++
drivers/infiniba
i40iw_hw.c, i40iw_utils.c and i40iw_osdep.h are files to handle
interrupts and processing.
Changes since v1:
Cleanup/removed some macros reported by Christoph Hellwig.
Acked-by: Anjali Singhai Jain
Acked-by: Shannon Nelson
Signed-off-by: Faisal Latif
---
drivers/infiniband/hw/i40iw/i4
i40iw_verbs.[ch] are to handle iwarp interface.
Changes since v2:
Made infiniband interface changes for 4.5
removed i40iw_reg_phys_mr() for 4.5
made changes as made by Christoph Hellwig made for nes
in i40iw_get_dma_mr().
Changes since v1:
Following modific
Add entry for port mapper services.
Changes since v2:
moved this patch before being used
Changes since v1:
moved I40IW as last element
Signed-off-by: Faisal Latif
---
include/uapi/rdma/rdma_netlink.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/rdma/rdma_net
From: Anjali Singhai Jain
This patch adds a Client interface for i40iw driver
support. Also expands the Virtchannel to support messages
from i40evf driver on behalf of i40iwvf driver.
This client API is used by the i40iw and i40iwvf driver
to access the core driver resources brokered by the i40e
This driver provides iWARP RDMA functionality for the Intel(R) X722 Ethernet
controller for PCI Physical Functions. It is in early product cycle
and having the driver in the kernel will allow users to have hardware support
when available for purchase.
i40iw cooperates with the Intel(R) X722 base
i40iw_cm.c i40iw_cm.h are used for connection management.
changes since v2:
Implemented interface changes as reg_phys_mr() is
not part of inifiniband interface Done as
Christoph Hellwig did for nes.
Changes since v1:
improved casts
moved kmap() from i40iw
On Wed, Jan 20, 2016 at 11:11 AM, Rustad, Mark D
wrote:
> Alexander Duyck wrote:
>
>> Actually you may want to go the other way on that. If they weren't
>> flipping the checksum value for GRE before why should we start doing
>> that now? I'm pretty sure the checksum mangling is a very UDP centr
On Wed, 2016-01-20 at 19:12 +, Edward Cree wrote:
> Thanks both, it's making more sense now.
> One thing I'm still unclear about: why does struct ethtool_usrip4_spechave
> the ip_ver field? The struct can't be extended to cover ipv6, because the
> address fields aren't big enough. So what's i
Thanks both, it's making more sense now.
One thing I'm still unclear about: why does struct ethtool_usrip4_spechave
the ip_ver field? The struct can't be extended to cover ipv6, because the
address fields aren't big enough. So what's it for?
Also, would it be appropriate to use struct in6_addr f
Alexander Duyck wrote:
Actually you may want to go the other way on that. If they weren't
flipping the checksum value for GRE before why should we start doing
that now? I'm pretty sure the checksum mangling is a very UDP centric
thing. There is no need to introduce it to other protocols.
I
The problem was caused by the RDMA_NL_LS_OP_RESOLVE request (not response)
packet sent by the user application, which falls through the netlink_dump path
and eventually calls ib_nl_handle_resp() with a new skb with uninitialized
control block. Checking the NETLINK_CB(skb).sk before calling netli
Am Mittwoch, 20. Januar 2016, 17:58:52 schrieb Nicolas Dichtel:
> Le 20/01/2016 15:00, Wolfgang Walter a écrit :
> > Hello,
> >
> > we tried 4.4 on our routers. We found one problem: 4.4 stops routing GRE
> > packets (ipv4 in GRE/ipv4) here. 4.4.15 works fine.
>
> 4.4.15 does not exist. Is it 4.1
On Wed, 2016-01-20 at 09:53 -0800, Alexander Duyck wrote:
> On Wed, Jan 20, 2016 at 9:10 AM, Edward Cree wrote:
> > I'm looking into adding IPv6 support to the ethtool flow steering API. But,
> > I don't know "the unfortunate history of and subtle differences between the
> > RX n-tuple versus RX
Begin forwarded message:
Date: Wed, 20 Jan 2016 10:14:17 +
From: "bugzilla-dae...@bugzilla.kernel.org"
To: "shemmin...@linux-foundation.org"
Subject: [Bug 111041] New: random openssh connection failure during connection
to server
https://urldefense.proofpoint.com/v2/url?u=https-3A__bug
On Wed, Jan 20, 2016 at 9:10 AM, Edward Cree wrote:
> I'm looking into adding IPv6 support to the ethtool flow steering API. But,
> I don't know "the unfortunate history of and subtle differences between the
> RX n-tuple versus RX NFC commands". In particular, would I need to add IPv6
> support
I'm looking into adding IPv6 support to the ethtool flow steering API. But,
I don't know "the unfortunate history of and subtle differences between the
RX n-tuple versus RX NFC commands". In particular, would I need to add IPv6
support to both of them, or only one? If one would be sufficient, wh
This is accidental, they don't depend on the label infrastructure.
Fixes: 48f66c905a97 ("netfilter: nft_ct: add byte/packet counter support")
Reported-by: Arnd Bergmann
Signed-off-by: Pablo Neira Ayuso
Acked-by: Florian Westphal
---
net/netfilter/nft_ct.c | 2 +-
1 file changed, 1 insertion(+)
From: Eric Dumazet
In case MSS option is added in TCP options, skb length increases by 4.
IPv6 needs to update skb->csum if skb has CHECKSUM_COMPLETE,
otherwise kernel complains loudly in netdev_rx_csum_fault() with a
stack dump.
Signed-off-by: Eric Dumazet
Signed-off-by: Pablo Neira Ayuso
---
From: Sasha Levin
When we need to lock all buckets in the connection hashtable we'd attempt to
lock 1024 spinlocks, which is way more preemption levels than supported by
the kernel. Furthermore, this behavior was hidden by checking if lockdep is
enabled, and if it was - use only 8 buckets(!).
Fi
From: Florian Westphal
Jozsef says:
The correct behaviour is that if we have
ipset create test1 hash:net,iface
ipset add test1 0.0.0.0/0,eth0
iptables -A INPUT -m set --match-set test1 src,src
then the rule should match for any traffic coming in through eth0.
This removes the -EINVAL runti
Unregister the chain type and return error, otherwise this leaks the
subscription to the netdevice notifier call chain.
Signed-off-by: Pablo Neira Ayuso
---
net/netfilter/nf_tables_netdev.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/nf_tables_netdev
From: Florian Westphal
David points out that we to three le/be conversions instead
of just one. Doesn't matter on x86_64 w. gcc, but other
architectures might be less lucky.
Since it also simplifies code just follow his advice.
Fixes: c0f3275f5cb ("nftables: byteorder: provide le/be 64 bit con
Hi David,
The following patchset contains Netfilter fixes for your net tree, they
are:
1) Fix accidental 3-times le/be conversion for 64-bits in nft_byteorder,
from Florian Westphal.
2) Get rid of defensive cidr = 0 check in the ipset hash:netiface set
type which doesn't allow valid 0.0.0.
On Wed, 2016-01-20 at 17:17 +0100, Jacob Siverskog wrote:
> On Wed, Jan 20, 2016 at 4:48 PM, Eric Dumazet wrote:
> > On Wed, 2016-01-20 at 16:06 +0100, Jacob Siverskog wrote:
> >> On Tue, Jan 5, 2016 at 3:39 PM, Eric Dumazet
> >> wrote:
> >> > On Tue, 2016-01-05 at 15:34 +0100, Jacob Siverskog w
On Wed, Jan 20, 2016 at 3:42 AM, Yishai Hadas wrote:
>> From: Bjorn Helgaas [mailto:bhelg...@google.com]
>> I assume you're tried booting with "pci=nomsi" or "mlx_core.msi_x=0"
>> and it works for you? Note that my board might be an internal design,
>> not a Mellanox board, so if it works for you
Le 20/01/2016 15:00, Wolfgang Walter a écrit :
Hello,
we tried 4.4 on our routers. We found one problem: 4.4 stops routing GRE
packets (ipv4 in GRE/ipv4) here. 4.4.15 works fine.
4.4.15 does not exist. Is it 4.1.15?
Hi,
On Wed, Jan 20, 2016 at 05:19:18PM +0100, Bjørn Mork wrote:
> Michael Grzeschik writes:
>
> > @@ -1263,6 +1271,10 @@ int register_c_can_dev(struct net_device *dev)
> > */
> > pinctrl_pm_select_sleep_state(dev->dev.parent);
> >
> > + priv->reg_xceiver = devm_regulator_get(priv->d
Hi Jacob,
On 01/05/2016 06:34 AM, Jacob Siverskog wrote:
> On Tue, Jan 5, 2016 at 3:14 PM, Eric Dumazet wrote:
>> On Tue, 2016-01-05 at 12:07 +0100, Jacob Siverskog wrote:
>>> On Mon, Jan 4, 2016 at 4:25 PM, Eric Dumazet wrote:
On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
>
1 - 100 of 117 matches
Mail list logo
