On Mon, Dec 4, 2017 at 9:35 PM, Shannon Nelson
wrote:
> Add a simple statistic to count the ipsec offloads.
>
> Signed-off-by: Shannon Nelson
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 28
> ++--
> dr
On Mon, Dec 4, 2017 at 9:35 PM, Shannon Nelson
wrote:
> If the skb has a security association referenced in the skb, then
> set up the Tx descriptor with the ipsec offload bits. While we're
> here, we fix an oddly named field in the context descriptor struct.
>
> Signed-off-by: Shannon Nelson
>
On Mon, Dec 4, 2017 at 9:35 PM, Shannon Nelson
wrote:
> If the chip sees and decrypts an ipsec offload, set up the skb
> sp pointer with the ralated SA info. Since the chip is rude
> enough to keep to itself the table index it used for the
> decryption, we have to do our own table lookup, using t
On Mon, Dec 4, 2017 at 9:35 PM, Shannon Nelson
wrote:
> On a chip reset most of the table contents are lost, so must be
> restored. This scans the driver's ipsec tables and restores both
> the filled and empty table slots to their pre-reset values.
>
> Signed-off-by: Shannon Nelson
> ---
> driv
On Mon, Dec 4, 2017 at 9:35 PM, Shannon Nelson
wrote:
> Add the functions for setting up and removing offloaded SAs (Security
> Associations) with the x540 hardware. We set up the callback structure
> but we don't yet set the hardware feature bit to be sure the XFRM service
> won't actually try t
On Mon, Dec 4, 2017 at 9:35 PM, Shannon Nelson
wrote:
> Set up the data structures to be used by the ipsec offload.
>
> Signed-off-by: Shannon Nelson
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 5
> drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.h | 40
> +++
On Mon, Dec 4, 2017 at 9:35 PM, Shannon Nelson
wrote:
> Add a few routines to make access to the ipsec registers just a little
> easier, and throw in the beginnings of an initialization.
>
> Signed-off-by: Shannon Nelson
> ---
> drivers/net/ethernet/intel/ixgbe/Makefile | 1 +
> drivers/n
On Mon, Dec 4, 2017 at 9:35 PM, Shannon Nelson
wrote:
> Add in the code for running and stopping the hardware ipsec
> encryption/decryption engine. It is good to keep the engine
> off when not in use in order to save on the power draw.
>
> Signed-off-by: Shannon Nelson
> ---
> drivers/net/ether
On Mon, Dec 4, 2017 at 11:52 AM, Michael Chan wrote:
> On Mon, Dec 4, 2017 at 10:43 AM, Alexander Duyck
> wrote:
>> On Mon, Dec 4, 2017 at 10:23 AM, Michael Chan
>> wrote:
>>> On Mon, Dec 4, 2017 at 8:47 AM, Alexander Duyck
>>> wrote:
>>>&
On Mon, Dec 4, 2017 at 11:26 AM, Eric Dumazet wrote:
> On Mon, 2017-12-04 at 13:59 -0500, David Miller wrote:
>> From: Alexander Duyck
>> Date: Mon, 4 Dec 2017 10:43:58 -0800
>>
>> > On Mon, Dec 4, 2017 at 10:23 AM, Michael Chan > m.com> wrote:
>> &g
On Mon, Dec 4, 2017 at 10:59 AM, David Miller wrote:
> From: Alexander Duyck
> Date: Mon, 4 Dec 2017 10:43:58 -0800
>
>> On Mon, Dec 4, 2017 at 10:23 AM, Michael Chan
>> wrote:
>>> On Mon, Dec 4, 2017 at 8:47 AM, Alexander Duyck
>>> wrote:
>>&g
On Mon, Dec 4, 2017 at 10:23 AM, Michael Chan wrote:
> On Mon, Dec 4, 2017 at 8:47 AM, Alexander Duyck
> wrote:
>> On Mon, Dec 4, 2017 at 3:12 AM, Michael Chan
>> wrote:
>>> Introduce NETIF_F_GRO_HW feature flag for NICs that support hardware
>>> GRO. With
On Mon, Dec 4, 2017 at 3:12 AM, Michael Chan wrote:
> Introduce NETIF_F_GRO_HW feature flag for NICs that support hardware
> GRO. With this flag, we can now independently turn on or off hardware
> GRO when GRO is on. Hardware GRO guarantees that packets can be
> re-segmented by TSO/GSO to recons
On Mon, Dec 4, 2017 at 1:51 AM, achiad shochat
wrote:
> On 3 December 2017 at 19:35, Stephen Hemminger
> wrote:
>> On Sun, 3 Dec 2017 11:14:37 +0200
>> achiad shochat wrote:
>>
>>> On 3 December 2017 at 07:05, Michael S. Tsirkin wrote:
>>> > On Fri, Dec 01, 2017 at 12:08:59PM -0800, Shannon Nel
On Fri, Dec 1, 2017 at 6:59 AM, Ganesh Goudar wrote:
> GRO is not supported by Chelsio HW when rx_csum is disabled.
> Update the netdev features flag when rx_csum is modified.
>
> Signed-off-by: Arjun Vynipadath
> Signed-off-by: Ganesh Goudar
> ---
> drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf
On Thu, Nov 30, 2017 at 9:11 AM, Stephen Hemminger
wrote:
> On Thu, 30 Nov 2017 10:47:21 -0500 (EST)
> David Miller wrote:
>
>> From: Stephen Hemminger
>> Date: Sun, 26 Nov 2017 10:17:47 -0800
>>
>> > This pair of patchesimproves the performance when running
>> > containers in an environment whe
On Wed, Nov 29, 2017 at 6:25 AM, Paolo Abeni wrote:
> Currently deleting qdisc with a large number of children and filters
> can take a lot of time:
>
> tc qdisc add dev lo root htb
> for I in `seq 1 1000`; do
> tc class add dev lo parent 1: classid 1:$I htb rate 100kbit
> tc qdisc
On Mon, Nov 20, 2017 at 3:35 PM, Sarah Newman wrote:
> On 11/20/2017 02:56 PM, Alexander Duyck wrote:
>> On Mon, Nov 20, 2017 at 2:38 PM, Sarah Newman
>> wrote:
>>> On 11/20/2017 08:36 AM, Alexander Duyck wrote:
>>>> Hi Sarah,
>>>>
>>>
On Mon, Nov 20, 2017 at 2:38 PM, Sarah Newman wrote:
> On 11/20/2017 08:36 AM, Alexander Duyck wrote:
>> Hi Sarah,
>>
>> I am adding the netdev mailing list as I am not certain this is an
>> i350 specific issue. The traces themselves aren't anything I recognize
&g
Hi Sarah,
I am adding the netdev mailing list as I am not certain this is an
i350 specific issue. The traces themselves aren't anything I recognize
as an existing issue. From what I can tell it looks like you are
running Xen, so would I be correct in assuming you are bridging
between VMs? If so ar
On Thu, Nov 16, 2017 at 9:41 AM, Or Gerlitz wrote:
> On Wed, Nov 15, 2017 at 1:05 AM, Alexander Duyck
> wrote:
>> On Tue, Nov 14, 2017 at 1:50 PM, Or Gerlitz wrote:
>
>>> all dealing with the sriov e-switch as a HW switch which should
>>> be programmed
>&g
On Tue, Nov 14, 2017 at 8:02 PM, Jakub Kicinski
wrote:
> On Tue, 14 Nov 2017 19:04:36 -0800, Alexander Duyck wrote:
>> On Tue, Nov 14, 2017 at 3:36 PM, Jakub Kicinski
>> wrote:
>> > On Tue, 14 Nov 2017 15:05:08 -0800, Alexander Duyck wrote:
>> >> >>
On Tue, Nov 14, 2017 at 3:36 PM, Jakub Kicinski
wrote:
> On Tue, 14 Nov 2017 15:05:08 -0800, Alexander Duyck wrote:
>> >> We basically need to do some feasability research to see if we can
>> >> actually meet all the requirements for switchdev on i40e. We have been
&
On Tue, Nov 14, 2017 at 1:50 PM, Or Gerlitz wrote:
> On Tue, Nov 14, 2017 at 10:00 PM, Alexander Duyck
> wrote:
>> On Tue, Nov 14, 2017 at 8:44 AM, Or Gerlitz wrote:
>>> On Mon, Nov 13, 2017 at 7:10 PM, Alexander Duyck
>>> wrote:
>>>> On Sun, N
On Tue, Nov 14, 2017 at 8:44 AM, Or Gerlitz wrote:
> On Mon, Nov 13, 2017 at 7:10 PM, Alexander Duyck
> wrote:
>> On Sun, Nov 12, 2017 at 10:16 PM, Or Gerlitz wrote:
>>> On Sun, Nov 12, 2017 at 10:38 PM, Alexander Duyck
>
>>> The what we call slow path requirem
On Mon, Nov 13, 2017 at 3:08 PM, Eric Dumazet wrote:
> On Mon, 2017-11-13 at 14:47 -0800, Alexander Duyck wrote:
>> On Mon, Nov 13, 2017 at 10:17 AM, Michael Ma wrote:
>> > 2017-11-12 16:14 GMT-08:00 Stephen Hemminger :
>> >> On Sun, 12 Nov 2017 13:43:13
On Mon, Nov 13, 2017 at 10:17 AM, Michael Ma wrote:
> 2017-11-12 16:14 GMT-08:00 Stephen Hemminger :
>> On Sun, 12 Nov 2017 13:43:13 -0800
>> Michael Ma wrote:
>>
>>> Any comments? We plan to implement this as a qdisc and appreciate any early
>>> feedback.
>>>
>>> Thanks,
>>> Michael
>>>
>>> > O
On Sun, Nov 12, 2017 at 10:16 PM, Or Gerlitz wrote:
> On Sun, Nov 12, 2017 at 10:38 PM, Alexander Duyck
> wrote:
>> On Sun, Nov 12, 2017 at 11:49 AM, Or Gerlitz wrote:
>>> Hi Dave and all,
>>>
>>> During and after the BoF on SRIOV switchdev mode,
On Sun, Nov 12, 2017 at 11:49 AM, Or Gerlitz wrote:
> Hi Dave and all,
>
> During and after the BoF on SRIOV switchdev mode, we came into a
> consensus among the developers from four different HW vendors (CC
> audience) that a correct thing to do would be to disallow any new
> extensions to the le
On Wed, Nov 8, 2017 at 4:21 PM, Keller, Jacob E
wrote:
>
>
>> -Original Message-----
>> From: Alexander Duyck [mailto:alexander.du...@gmail.com]
>> Sent: Wednesday, November 08, 2017 3:04 PM
>> To: Keller, Jacob E
>> Cc: Brandeburg, Jesse ; ne
On Wed, Nov 8, 2017 at 2:05 PM, Keller, Jacob E
wrote:
>> -Original Message-
>> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
>> Of
>> Jesse Brandeburg
>> Sent: Friday, November 03, 2017 10:06 AM
>> To: Alexander Duyck
On Wed, Nov 8, 2017 at 9:12 AM, Fengguang Wu wrote:
> Hi Linus,
>
>
> On Wed, Nov 08, 2017 at 08:20:38AM -0800, Linus Torvalds wrote:
>>
>> On Wed, Nov 8, 2017 at 1:48 AM, Fengguang Wu
>> wrote:
>>>
>>>
>>> Now I got the faddr2line output. :)
>>
>>
>> Thank you, but this also shows that you then
On Mon, Nov 6, 2017 at 10:37 AM, Pieter Jansen van Vuuren
wrote:
> On Fri, 3 Nov 2017 11:50:47 -0400
> Manish Kurup wrote:
>
>> Using a spinlock in the VLAN action causes performance issues when the VLAN
>> action is used on multiple cores. Rewrote the VLAN action to use RCU read
>> locking for
On Thu, Nov 2, 2017 at 4:34 PM, Alexander Duyck
wrote:
> From: Alexander Duyck
>
> This update makes it so that we report the actual number of Tx queues via
> real_num_tx_queues but are still restricted to RSS on only the first pool
> by setting num_tc equal to 1. Doing this loc
From: Alexander Duyck
This patch is mostly just a minor clean-up so that we avoid letting a
packet jump from one traffic class to another just based on the Rx queue.
Instead we now use that queue number as an offset within the traffic class.
Handling it this way allows us to operate more cleanly
From: Alexander Duyck
With the recent fix to ixgbe we can cap the number of queues always
regardless of if accel_priv is being used or not since the actual number of
queues are being reported via real_num_tx_queues.
Signed-off-by: Alexander Duyck
---
net/core/dev.c |3 +--
1 file changed
From: Alexander Duyck
This update makes it so that we report the actual number of Tx queues via
real_num_tx_queues but are still restricted to RSS on only the first pool
by setting num_tc equal to 1. Doing this locks us into only having the
ability to setup XPS on the queues in that pool, and
From: Alexander Duyck
When SR-IOV was enabled the macvlan offload was configuring several filters
with the wrong pool value. This would result in the macvlan interfaces not
being able to receive traffic that had to pass over the physical interface.
To fix it wrap the pool argument in the VMDQ_P
From: Alexander Duyck
The fm10k driver didn't work correctly when macvlan offload was enabled.
Specifically what would occur is that we would see no unicast packets being
received. This was traced down to us not correctly configuring the default
VLAN ID for the port and defaulting to 0
at we don't want packets to somehow stray and end up
being transmitted on a queue that is supposed to be in use by a macvlan
instead of the lowerdev itself.
---
Alexander Duyck (5):
ixgbe: Fix interaction between SR-IOV and macvlan offload
fm10k: Fix VLAN configuration for macvl
On Fri, Oct 27, 2017 at 3:22 PM, Subash Abhinov Kasiviswanathan
wrote:
>> This doesn't make sense to me, maybe I am missing something. What
>> "real device" is setting the skb->destructor() and doing it to somehow
>> handle recycling? The only driver I can find that is setting
>> skb->desctructor(
same fix is already there. All this is checking for is to make
certain we don't span too many descriptors. We added that fix close to
a year ago. Take a look at the following, it is the last fix in the
set for the same issue:
commit 841493a3f64395b60554afbcaa17f4350f90e764
Author: Alexande
On Fri, Oct 27, 2017 at 1:30 PM, Subash Abhinov Kasiviswanathan
wrote:
> For deaggregation, the real device receives a large linear skb and
> passes it on to rmnet. rmnet creates new skbs from this large frame.
>
> If the real device supports recycling, it does not need to allocate
> the large skb
On Thu, Oct 26, 2017 at 8:25 AM, Paweł Staszewski wrote:
> Server after runing for about 40 hours is starting to loose all links on all
> nics.
>
> Warning from : Kernel 4.12.14
>
> Latest working kernel 4.11.12
>
> all kernels >4.14 - have same problem but less in debug info
>
>
> Below warning f
r before the block callbacks were
>>> introduced. Allow the drivers to do binding of block always, no matter
>>> if the NETIF_F_HW_TC feature is on or off. Move the check to the block
>>> callback which is called for rule insertion.
>>>
>>> Reported-by:
On Tue, Oct 24, 2017 at 9:01 AM, Alexander Duyck
wrote:
> On Fri, Oct 20, 2017 at 7:04 PM, David Miller wrote:
>> From: Jiri Pirko
>> Date: Thu, 19 Oct 2017 15:50:28 +0200
>>
>>> This patchset is a bit bigger, but most of the patches are doing the
>>> s
On Fri, Oct 20, 2017 at 7:04 PM, David Miller wrote:
> From: Jiri Pirko
> Date: Thu, 19 Oct 2017 15:50:28 +0200
>
>> This patchset is a bit bigger, but most of the patches are doing the
>> same changes in multiple classifiers and drivers. I could do some
>> squashes, but I think it is better spli
From: Alexander Duyck
This patch updates the i40e driver to include programming descriptors in
the cleaned_count. Without this change it becomes possible for us to leak
memory as we don't trigger a large enough allocation when the time comes to
allocate new buffers and we end up overwrit
From: Alexander Duyck
This reverts commit 11f29003d6376fb123b7c3779dba49bb56fb0815.
I am reverting this as I am fairly certain this can result in a memory leak
when combined with the current page recycling scheme. Specifically we end
up attempting to allocate fewer buffers than we recycled and
On Tue, Oct 17, 2017 at 10:37 PM, Nambiar, Amritha
wrote:
> On 10/17/2017 10:33 AM, Alexander Duyck wrote:
>> On Tue, Oct 17, 2017 at 8:49 AM, Arnd Bergmann wrote:
>>> The new bandwidth calculation caused a link error on 32-bit
>>> architectures, like
>>>
&g
of unneeded complexity I introduced here. It
looks like we have the same problem in ixgbe that needs to be
addressed as well.
Fixes: 7cc6fd4c60f2 ("igb: Don't bother clearing Tx buffer_info in
igb_clean_tx_ring")
Acked-by: Alexander Duyck
On Wed, Oct 18, 2017 at 4:51 PM, Paweł Staszewski wrote:
>
>
> W dniu 2017-10-19 o 01:37, Alexander Duyck pisze:
>
>> On Wed, Oct 18, 2017 at 4:22 PM, Paweł Staszewski
>> wrote:
>>>
>>>
>>> W dniu 2017-10-19 o 00:58, Paweł Staszewski pisze:
&
On Thu, Oct 19, 2017 at 4:41 AM, Pavlos Parissis
wrote:
> On 19 October 2017 at 01:40, Paweł Staszewski wrote:
>>
>>
>> W dniu 2017-10-19 o 01:29, Alexander Duyck pisze:
>>
>>> On Mon, Oct 16, 2017 at 10:51 PM, Vitezslav Samel
>>> wrote:
>>>
On Thu, Oct 19, 2017 at 5:19 AM, Anders K. Pedersen | Cohaesio
wrote:
> Hi Alex,
>
> On ons, 2017-10-18 at 16:37 -0700, Alexander Duyck wrote:
>> When we last talked I had asked if you could do a git bisect to find
>> the memory leak and you said you would look into it. The
>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> W dniu 2017-10-17 o 12:59, Paweł Staszewski pisze:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>&g
On Mon, Oct 16, 2017 at 10:51 PM, Vitezslav Samel wrote:
> On Tue, Oct 17, 2017 at 01:34:29AM +0200, Paweł Staszewski wrote:
>> W dniu 2017-10-16 o 18:26, Paweł Staszewski pisze:
>> > W dniu 2017-10-16 o 13:20, Pavlos Parissis pisze:
>> > > On 15/10/2017 0
On Tue, Oct 17, 2017 at 2:18 PM, Shannon Nelson
wrote:
> This patch adds support for macvlan hardware offload (l2-fwd-offload)
> feature using the XL710's macvlan-to-queue filtering machanism. These
> are most useful for supporting separate mac addresses for Container
> virtualization using Docke
need to test it to verify it
doesn't break existing functionality. In the meantime if Alan's patch
has gone through testing we should probably push "i40e: fix u64
division usage" to Dave so that we can at least fix the linking issues
on ARM and i386.
Reviewe
d should now be able to provide a performance advantage of
skipping the checks on the lower dev while not introducing any sort of
regression.
Signed-off-by: Alexander Duyck
---
drivers/net/macvlan.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/mac
From: Alexander Duyck
I overlooked the fact that netdev_txq_to_tc was not an exported symbol. To
fix that I am providing the export for the symbol in order to avoid
breaking builds where mqprio is not built into the kernel.
Signed-off-by: Alexander Duyck
---
net/core/dev.c |1 +
1 file
On Mon, Oct 16, 2017 at 4:34 PM, Paweł Staszewski wrote:
>
>
> W dniu 2017-10-16 o 18:26, Paweł Staszewski pisze:
>
>>
>>
>> W dniu 2017-10-16 o 13:20, Pavlos Parissis pisze:
>>>
>>> On 15/10/2017 02:58 πμ, Alexander Duyck wrote:
>>>>
&g
On Mon, Oct 16, 2017 at 3:24 AM, Neftin, Sasha wrote:
> On 10/11/2017 12:07, David Laight wrote:
>>
>> From: Jeff Kirsher
>>>
>>> Sent: 10 October 2017 18:22
>>> Intel 100/200 Series Chipset platforms reduced the round-trip
>>> latency for the LAN Controller DMA accesses, causing in some high
>>>
On Mon, Oct 16, 2017 at 4:20 AM, Pavlos Parissis
wrote:
> On 15/10/2017 02:58 πμ, Alexander Duyck wrote:
>> Hi Pawel,
>>
>> To clarify is that Dave Miller's tree or Linus's that you are talking
>> about? If it is Dave's tree how long ago was it you p
o
> reply for year or more - or if somebody reply after year they are closing
> ticket after 1 day with info about no activity :)
>
>
>
> W dniu 2017-10-05 o 07:19, Anders K. Pedersen | Cohaesio pisze:
>
> On ons, 2017-10-04 at 08:32 -0700, Alexander Duyck wrote:
>
> On
So this patch series is just a few minor cleanups for macvlan source mode.
The first patch addresses double receives when a packet is being routed to
the macvlan destination address, and the other addresses the pkt_type being
updated in cases where it most likely should not be.
---
Alexander
From: Alexander Duyck
This patch intoduces a slight adjustment for macvlan to address the fact
that in source mode I was seeing two copies of any packet addressed to the
macvlan interface being delivered where there should have been only one.
The issue appears to be that one copy was delivered
From: Alexander Duyck
This patch updates the pkt_type to PACKET_HOST only if the destination MAC
address matches on the on the source based macvlan. It didn't make sense to
be updating broadcast, multicast, and non-local destined frames with
PACKET_HOST.
Signed-off-by: Alexander
From: Alexander Duyck
This patch makes a slight tweak to mqprio in order to bring the
classid values used back in line with what is used for mq. The general idea
is to reserve values :ffe0 - :ffef to identify hardware traffic classes
normally reported via dev->num_tc. By doing this we
On Thu, Oct 12, 2017 at 8:59 AM, Jesus Sanchez-Palencia
wrote:
> Hi Alex,
>
>
> On 10/12/2017 08:21 AM, Alexander Duyck wrote:
>> On Wed, Oct 11, 2017 at 5:54 PM, Vinicius Costa Gomes
>> wrote:
>>> From: Jesus Sanchez-Palencia
>>>
>>> When r
On Wed, Oct 11, 2017 at 5:54 PM, Vinicius Costa Gomes
wrote:
> From: Jesus Sanchez-Palencia
>
> When replacing a child qdisc from mqprio, tc_modify_qdisc() must fetch
> the netdev_queue pointer that the current child qdisc is associated
> with before creating the new qdisc.
>
> Currently, when us
On Wed, Oct 11, 2017 at 1:58 PM, Jiri Pirko wrote:
> Wed, Oct 11, 2017 at 10:46:52PM CEST, da...@davemloft.net wrote:
>>From: Jiri Pirko
>>Date: Wed, 11 Oct 2017 22:38:32 +0200
>>
>>> Wed, Oct 11, 2017 at 07:46:27PM CEST, alexander.du...@gmail.com wrote:
On Wed, Oct 11, 2017 at 5:56 AM, Jiri
On Wed, Oct 11, 2017 at 5:56 AM, Jiri Pirko wrote:
> Wed, Oct 11, 2017 at 02:24:12AM CEST, amritha.namb...@intel.com wrote:
>>This patch series enables configuring cloud filters in i40e
>>using the tc-flower classifier. The classification function
>>of the filter is to match a packet to a class. c
On Mon, Oct 9, 2017 at 10:30 AM, Alexander Duyck
wrote:
> On Sun, Oct 8, 2017 at 6:07 PM, Eric Dumazet wrote:
>> On Sun, 2017-10-08 at 15:54 -0700, Alexander Duyck wrote:
>>> From: Alexander Duyck
>>>
>>> This patch intoduces a slight adjustment for mac
On Sun, Oct 8, 2017 at 6:07 PM, Eric Dumazet wrote:
> On Sun, 2017-10-08 at 15:54 -0700, Alexander Duyck wrote:
>> From: Alexander Duyck
>>
>> This patch intoduces a slight adjustment for macvlan to address the fact
>> that in source mode I was seeing two copies of
On Mon, Oct 9, 2017 at 2:07 AM, David Laight wrote:
> From: Jeff Kirsher
>> Sent: 06 October 2017 18:57
>> From: Jacob Keller
>>
>> Since commit 6a7fded776a7 ("i40e: Fix RS bit update in Tx path and
>> disable force WB workaround") we've tried to "optimize" setting the
>> RS bit based around skb-
From: Alexander Duyck
This patch intoduces a slight adjustment for macvlan to address the fact
that in source mode I was seeing two copies of any packet addressed to the
macvlan interface being delivered where there should have been only one.
The issue appears to be that one copy was delivered
On Thu, Oct 5, 2017 at 2:07 PM, Bjorn Helgaas wrote:
> On Wed, Oct 04, 2017 at 04:29:14PM -0700, Alexander Duyck wrote:
>> On Wed, Oct 4, 2017 at 4:01 PM, Bjorn Helgaas wrote:
>> > On Wed, Oct 04, 2017 at 08:52:58AM -0700, Tony Nguyen wrote:
>> >> This fixes a bug
fs.
The problem is you don't want to write the full iov->ctrl value until
after you have reset the the number of VFs since it will set VFE so
pulling out and configuring the ARI value separately is needed.
>> This can cause the iov
>> structure to be populated with values that are incorrect
From: Alexander Duyck
It looks like we weren't correctly placing the pages from buffers that had
been used to return a filter programming status back on the ring. As a
result they were being overwritten and tracking of the pages was lost.
This change works to correct that by incorporating
On Wed, Oct 4, 2017 at 5:56 AM, Anders K. Pedersen | Cohaesio
wrote:
> Hello,
>
> After updating one of our Linux based routers to kernel 4.13 it began
> leaking memory quite fast (about 1 GB every half hour). To narrow we
> tried various kernel versions and found that 4.11.12 is okay, while
> 4.1
On Fri, Sep 29, 2017 at 2:13 AM, wangyunjian wrote:
>
>
>> -Original Message-----
>> From: Alexander Duyck [mailto:alexander.du...@gmail.com]
>> Sent: Thursday, September 28, 2017 11:44 PM
>> To: wangyunjian
>> Cc: David Miller ; Jeff Kirsher
>>
On Wed, Sep 27, 2017 at 7:01 PM, w00273186 wrote:
> From: Yunjian Wang
>
> Now it doesn't limit the number of MAC/VLAN strictly. When there is more
> elements in the virtchnl MAC/VLAN list, it can still add successfully.
You could still add but should you. I'm not clear from this patch
descripti
From: Alexander Duyck
The following change is meant to update the adaptive ITR algorithm to
better support the needs of the network. Specifically with this change what
I have done is make it so that our ITR algorithm will try to prevent either
starving a socket buffer for memory in the case of
usly. Fix this by skipping over the read of p on an invalid
> stat type.
>
> Detected by CoverityScan, CID#113385 ("Explicit null dereferenced")
>
> Signed-off-by: Colin Ian King
Looks good to me.
Reviewed-by: Alexander Duyck
> ---
> drivers/net/ethernet/in
On Fri, Sep 22, 2017 at 6:41 AM, Colin King wrote:
> From: Colin Ian King
>
> Currently if the stat type is invalid then data[i] is being set
> either by dereferencing a null pointer p, or it is reading from
> an incorrect previous location if we had a valid stat type
> previously. Fix this by n
On Thu, Sep 14, 2017 at 12:59 PM, Maxim Uvarov wrote:
> debugfs here is very very useful to read registers directly and
> compare what use space tools see. Cool feature to get regs by port and
> use standard tools to diff and print them. Even might be better to
> allow drivers to decode register n
On Mon, Sep 11, 2017 at 3:07 PM, Tom Herbert wrote:
> On Mon, Sep 11, 2017 at 9:49 AM, Samudrala, Sridhar
> wrote:
>> On 9/10/2017 8:19 AM, Tom Herbert wrote:
>>>
>>> On Thu, Aug 31, 2017 at 4:27 PM, Sridhar Samudrala
>>> wrote:
This patch introduces a new socket option SO_SYMMETRIC_QU
On Mon, Sep 11, 2017 at 9:48 AM, Samudrala, Sridhar
wrote:
>
>
> On 9/9/2017 6:28 PM, Alexander Duyck wrote:
>>
>> On Thu, Aug 31, 2017 at 4:27 PM, Sridhar Samudrala
>> wrote:
>>>
>>> This patch introduces a new socket option SO_SYMMETRIC_QUEUES th
On Thu, Aug 31, 2017 at 4:27 PM, Sridhar Samudrala
wrote:
> This patch introduces a new socket option SO_SYMMETRIC_QUEUES that can be used
> to enable symmetric tx and rx queues on a socket.
>
> This option is specifically useful for epoll based multi threaded workloads
> where each thread handles
On Wed, Sep 6, 2017 at 9:17 AM, Tom Herbert wrote:
> On Tue, Sep 5, 2017 at 8:06 PM, Alexander Duyck
> wrote:
>> On Tue, Sep 5, 2017 at 2:13 PM, Tom Herbert wrote:
>>>> The situation with encapsulation is even more complicated:
>>>>
>>>> W
On Tue, Sep 5, 2017 at 2:13 PM, Tom Herbert wrote:
>> The situation with encapsulation is even more complicated:
>>
>> We are basically only interested in the UDP/vxlan/Ethernet/IP/UDP
>> constellation. If we do the fragmentation inside the vxlan tunnel and
>> carry over the skb hash to all result
On Fri, Sep 1, 2017 at 3:54 AM, Jesper Dangaard Brouer
wrote:
> The ixgbe driver have page recycle scheme based around the RX-ring
> queue, where a RX page is shared between two packets. Based on the
> refcnt, the driver can determine if the RX-page is currently only used
> by a single packet, if
On Tue, Aug 29, 2017 at 12:02 PM, Andy Gospodarek wrote:
> On Tue, Aug 29, 2017 at 09:23:49AM -0700, Alexander Duyck wrote:
>> On Tue, Aug 29, 2017 at 6:26 AM, Jesper Dangaard Brouer
>> wrote:
>> >
>> > On Mon, 28 Aug 2017 09:11:25 -0700 Alexander Duyck
>&g
On Tue, Aug 29, 2017 at 6:26 AM, Jesper Dangaard Brouer
wrote:
>
> On Mon, 28 Aug 2017 09:11:25 -0700 Alexander Duyck
> wrote:
>
>> My advice would be to not over complicate this. My big concern with
>> all this buffer recycling is what happens the first time somebody
On Fri, Aug 25, 2017 at 3:28 PM, Stefano Brivio wrote:
> On Fri, 25 Aug 2017 15:10:08 -0700
> Alexander Duyck wrote:
>
>> On Fri, Aug 25, 2017 at 1:52 PM, Stefano Brivio wrote:
>>
>> [...]
>>
>> > Once patches reach Intel's patchwork, will they
rst values earlier, where explicitly
>> initialized module variables can be distinguished from defaults.
>>
>> Signed-off-by: Willem de Bruijn
>
> This patch looks good for me, but I would like hear second opinion.
This code is an improvement over what was already there. I am good with this.
Acked-by: Alexander Duyck
ug 2017 20:36:28 -0700
>> >> Michael Chan wrote:
>> >>
>> >>> On Wed, Aug 23, 2017 at 1:29 AM, Jesper Dangaard Brouer
>> >>> wrote:
>> >>>> On Tue, 22 Aug 2017 23:59:05 -0700
>> >>>> Michael Chan wrote
On Fri, Aug 25, 2017 at 8:58 AM, Stephen Hemminger
wrote:
> On Fri, 25 Aug 2017 15:36:22 +
> "Waskiewicz Jr, Peter" wrote:
>
>> On 8/25/17 11:25 AM, Jacob Keller wrote:
>> > Under some circumstances, such as with many stacked devices, it is
>> > possible that dev_hard_start_xmit will bundle m
On Fri, Aug 25, 2017 at 1:52 PM, Stefano Brivio wrote:
> Hi,
>
> As I'm currently preparing another fix for i40e, and the last one I
> submitted has been stuck for about two weeks now, I would like to ask
> some details about the process to submit fixes for i40e/i40evf drivers,
> before I do somet
Fri, Aug 25, 2017 at 7:16 AM, Andrew Lunn wrote:
> On Fri, Aug 25, 2017 at 08:47:00AM -0500, Larry Finger wrote:
>> On 08/24/2017 08:54 PM, Andrew Lunn wrote:
>> >netdev frowns upon debugfs. You should try to keep this altogether,
>> >making it easy to throw away before the driver is moved out of
701 - 800 of 1940 matches
Mail list logo
