On Tue, Aug 22, 2017 at 11:59 PM, Michael Chan
wrote:
> On Tue, Aug 22, 2017 at 6:06 PM, Alexander Duyck
> wrote:
>> On Tue, Aug 22, 2017 at 1:04 PM, Michael Chan
>> wrote:
>>>
>>> Right, but it's conceivable to add an API to "return" the buf
On Tue, Aug 22, 2017 at 1:04 PM, Michael Chan wrote:
> On Tue, Aug 22, 2017 at 11:30 AM, Duyck, Alexander H
> wrote:
>> On Tue, 2017-08-22 at 11:17 -0700, John Fastabend wrote:
>>> On 08/22/2017 11:02 AM, Michael Chan wrote:
>>> > On Mon, Aug 21, 2017 at 12:25 PM, Jesper Dangaard Brouer
>>> > wr
On Wed, Aug 16, 2017 at 2:41 AM, Ding Tianhong wrote:
> The ixgbe driver use the compile check to determine if it can
> send TLPs to Root Port with the Relaxed Ordering Attribute set,
> this is too inconvenient, now the new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING
> has been added to the kernel and
On Sat, Aug 12, 2017 at 10:27 AM, Paweł Staszewski
wrote:
> Hi and thanks for reply
>
>
>
> W dniu 2017-08-12 o 14:23, Jesper Dangaard Brouer pisze:
>>
>> On Fri, 11 Aug 2017 19:51:10 +0200 Paweł Staszewski
>> wrote:
>>
>>> Hi
>>>
>>> I made some tests for performance comparison.
>>
>> Thanks for
my acked-by, but it is mostly related to how this
interacts with NICs, and not so much about the PCI chipsets
themselves.
Acked-by: Alexander Duyck
On Thu, Jul 13, 2017 at 11:14 AM, Alexander Duyck
wrote:
> On Thu, Jul 13, 2017 at 7:21 AM, Ding Tianhong
> wrote:
>> From: Casey Leedom
>>
>> cxgb4 Ethernet driver now queries PCIe configuration space to determine
>> if it can send TLPs to it with the
On Thu, Jul 13, 2017 at 7:21 AM, Ding Tianhong wrote:
> From: Casey Leedom
>
> cxgb4 Ethernet driver now queries PCIe configuration space to determine
> if it can send TLPs to it with the Relaxed Ordering Attribute set.
>
> Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability
On Mon, Jul 10, 2017 at 5:01 PM, Casey Leedom wrote:
>
> Hey Alexander,
>
> Okay, I understand your point regarding the "most likely scenario" being
> TLPs directed upstream to the Root Complex. But I'd still like to make sure
> that we have an agreed upon API/methodology for doing Peer-to-Peer
On Fri, Jul 7, 2017 at 7:04 PM, Casey Leedom wrote:
> Okay, thanks for the note Alexander. I'll have to look more closely at
> the patch on Monday and try it out on one of the targeted systems to verify
> the semantics you describe.
>
> However, that said, there is no way to tell a priori whe
On Fri, Jul 7, 2017 at 5:30 PM, Casey Leedom wrote:
> By the way, it ~seems~ like the patch set confuses the idea of the PCIe
> Capability Device Control[Relaxed Ordering Enable] with the device's ability
> to handle incoming TLPs with the Relaxed Ordering Attribute set. These are
> complete
On Sun, Jun 18, 2017 at 11:53 PM, Ding Tianhong wrote:
> From: Casey Leedom
>
> cxgb4 Ethernet driver now queries PCIe configuration space to determine
> if it can send TLPs to it with the Relaxed Ordering Attribute set.
>
> Signed-off-by: Casey Leedom
> Signed-off-by: Ding Tianhong
> ---
> dr
On Wed, Jun 21, 2017 at 10:54 AM, John Fastabend
wrote:
> On 06/21/2017 10:27 AM, Daniel Borkmann wrote:
>> Fill the bpf_prog with the id just like we do in other XDP enabled
>> drivers.
>>
>> Signed-off-by: Daniel Borkmann
>> Cc: Martin KaFai Lau
>> Cc:
On Fri, Jun 16, 2017 at 11:10 AM, Christoph Hellwig wrote:
> DMA_ERROR_CODE is not a public API and will go away. Instead properly
> unwind based on the loop counter.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Dave Jiang
> Acked-By: Vinod Koul
> ---
> drivers/dma/ioat/init.c | 24 ++
On Thu, Jun 15, 2017 at 6:10 PM, Ding Tianhong wrote:
>
>
> On 2017/6/13 5:28, Alexander Duyck wrote:
>> On Mon, Jun 12, 2017 at 4:05 AM, Ding Tianhong
>> wrote:
> ...
>>> /**
>>> + * pcie_clear_relaxed_ordering - clear PCI Express relaxed orde
On Mon, Jun 12, 2017 at 4:05 AM, Ding Tianhong wrote:
> From: Casey Leedom
>
> cxgb4 Ethernet driver now queries PCIe configuration space to determine
> if it can send TLPs to it with the Relaxed Ordering Attribute set.
>
> Signed-off-by: Casey Leedom
> Signed-off-by: Ding Tianhong
Casey, does
On Mon, Jun 12, 2017 at 4:05 AM, Ding Tianhong wrote:
> The PCIe Device Control Register use the bit 4 to indicate that
> whether the device is permitted to enable relaxed ordering or not.
> But relaxed ordering is not safe for some platform which could only
> use strong write ordering, so devices
On Sat, Jun 10, 2017 at 4:33 AM, Dan Carpenter wrote:
>
> This patch isn't right...
>
> On Wed, Jun 07, 2017 at 12:54:07AM +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> key has previously been null checked so the subsequent null check
>> is redundant as key can never be null at that poin
On Fri, Jun 9, 2017 at 3:34 AM, Adrian Tomasov wrote:
> On Thu, 2017-06-01 at 19:18 +, Duyck, Alexander H wrote:
>> On Thu, 2017-06-01 at 12:14 +0200, Adrian Tomasov wrote:
>> >
>> > On Wed, 2017-05-31 at 14:42 -0700, Alexander Duyck wrote:
>> > >
>&g
On Wed, Jun 7, 2017 at 2:16 AM, Ding Tianhong wrote:
> From: Casey Leedom
>
> cxgb4 Ethernet driver now queries Root Complex Port to determine if it can
> send TLPs to it with the Relaxed Ordering Attribute set.
>
> Signed-off-by: Casey Leedom
> Signed-off-by: Ding Tianhong
So I am pretty sure
On Mon, Jun 5, 2017 at 6:33 AM, Ding Tianhong wrote:
>
>
> On 2017/6/4 2:19, Alexander Duyck wrote:
>> On Fri, Jun 2, 2017 at 9:04 PM, Ding Tianhong
>> wrote:
>>> The PCIe Device Control Register use the bit 4 to indicate that
>>> whether the device is
On Fri, Jun 2, 2017 at 9:04 PM, Ding Tianhong wrote:
> The PCIe Device Control Register use the bit 4 to indicate that
> whether the device is permitted to enable relaxed ordering or not.
> But relaxed ordering is not safe for some platform which could only
> use strong write ordering, so devices
On Wed, May 31, 2017 at 6:48 AM, Adrian Tomasov wrote:
> On Tue, 2017-05-30 at 18:27 -0700, Alexander Duyck wrote:
>> On Tue, May 30, 2017 at 8:41 AM, Alexander Duyck
>> wrote:
>> >
>> > On Tue, May 30, 2017 at 6:43 AM, Adam Okuliar
>> > wrote:
&
On Tue, May 30, 2017 at 8:41 AM, Alexander Duyck
wrote:
> On Tue, May 30, 2017 at 6:43 AM, Adam Okuliar wrote:
>> Hello,
>>
>> we found regression on intel card(XL710) with i40e driver. Regression is
>> about ~45%
>> on TCP_STREAM and TCP_MAERTS test for IP
On Tue, May 30, 2017 at 6:43 AM, Adam Okuliar wrote:
> Hello,
>
> we found regression on intel card(XL710) with i40e driver. Regression is
> about ~45%
> on TCP_STREAM and TCP_MAERTS test for IPv4 and IPv6. Regression was first
> visible in kernel-4.12.0-0.rc1.
>
> More details about results you c
On Thu, May 25, 2017 at 6:35 AM, Ding Tianhong wrote:
>
> On 2017/5/9 8:48, Casey Leedom wrote:
>>
>> | From: Alexander Duyck
>> | Date: Saturday, May 6, 2017 11:07 AM
>> |
>> | | From: Ding Tianhong
>> | | Date: Fri, May 5, 2017 at 8:08 PM
>> |
On Fri, May 19, 2017 at 5:58 PM, Amritha Nambiar
wrote:
> The i40e driver is modified to enable the new mqprio hardware
> offload mode and factor the TCs and queue configuration by
> creating channel VSIs. In this mode, the priority to traffic
> class mapping and the user specified queue ranges ar
On Fri, May 19, 2017 at 5:58 PM, Amritha Nambiar
wrote:
> This patch introduces a new hardware offload mode in mqprio
> which makes full use of the mqprio options, the TCs, the
> queue configurations and the bandwidth rates for the TCs.
> This is achieved by setting the value 2 for the "hw" option
On Fri, May 19, 2017 at 5:58 PM, Amritha Nambiar
wrote:
> This patch sets up the infrastructure for offloading TCs and
> queue configurations to the hardware by creating HW channels(VSI).
> A new channel is created for each of the traffic class
> configuration offloaded via mqprio framework except
On Mon, May 22, 2017 at 4:59 PM, David Miller wrote:
> From: Vladislav Yasevich
> Date: Thu, 18 May 2017 09:31:03 -0400
>
>> It appears that since commit 8cb65d000, Q-in-Q vlans have been
>> broken. The series that commit is part of enabled TSO and checksum
>> offloading on Q-in-Q vlans. Howeve
On Sat, May 20, 2017 at 2:15 PM, Or Gerlitz wrote:
> On Sat, May 20, 2017 at 3:58 AM, Amritha Nambiar
> wrote:
>> The following series introduces a new harware offload mode in tc/mqprio
>
> Wait, we have already a HW QoS model introduced by John F and Co
> couple of years ago, right?
I assume y
On Tue, May 16, 2017 at 11:38 AM, Casey Leedom wrote:
> | From: Ding Tianhong
> | Sent: Wednesday, May 10, 2017 6:15 PM
> |
> | Hi Casey:
> |
> | Will you continue to work on this solution or send a new version patches?
>
> I won't be able to work on this any time soon given several other urgent
On Sun, May 14, 2017 at 10:56 AM, Björn Töpel wrote:
> From: Björn Töpel
>
> In f8b45b74cc62 ("i40e/i40evf: Use build_skb to build frames")
> i40e_build_skb updates the page_offset field with an incorrect offset,
> which can lead to data corruption. This patch updates page_offset
> correctly.
>
>
On Mon, May 8, 2017 at 7:33 AM, Ding Tianhong wrote:
>
>
> On 2017/5/7 2:07, Alexander Duyck wrote:
>> On Fri, May 5, 2017 at 8:08 PM, Ding Tianhong
>> wrote:
>>>
>>>
>>> On 2017/5/5 22:04, Alexander Duyck wrote:
>>>> On Thu, May 4, 2
On Fri, May 5, 2017 at 8:08 PM, Ding Tianhong wrote:
>
>
> On 2017/5/5 22:04, Alexander Duyck wrote:
>> On Thu, May 4, 2017 at 2:01 PM, Casey Leedom wrote:
>>> | From: Alexander Duyck
>>> | Sent: Wednesday, May 3, 2017 9:02 AM
>>> | ...
>>> |
put.
>
> Signed-off-by: Vladislav Yasevich
Acked-by: Alexander Duyck
> ---
> V2: posted the right patch.
>
> net/8021q/vlan_dev.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
> inde
On Fri, May 5, 2017 at 12:20 PM, Vladislav Yasevich wrote:
> Vlan devices, like all other software devices, enable
> NETIF_F_HW_CSUM feature. However, unlike all the othe other
> software devices, vlans will switch to using IP|IPV6_CSUM
> features, if the underlying devices uses them. In these s
On Thu, May 4, 2017 at 2:01 PM, Casey Leedom wrote:
> | From: Alexander Duyck
> | Sent: Wednesday, May 3, 2017 9:02 AM
> | ...
> | It sounds like we are more or less in agreement. My only concern is
> | really what we default this to. On x86 I would say we could probably
>
On Tue, May 2, 2017 at 9:30 PM, Casey Leedom wrote:
> | From: Alexander Duyck
> | Date: Tuesday, May 2, 2017 11:10 AM
> | ...
> | So for example, in the case of x86 it seems like there are multiple
> | root complexes that have issues, and the gains for enabling it with
> | st
On Tue, May 2, 2017 at 12:34 PM, Raj, Ashok wrote:
> On Tue, May 02, 2017 at 11:10:22AM -0700, Alexander Duyck wrote:
>> On Tue, May 2, 2017 at 9:53 AM, Raj, Ashok wrote:
>> > On Tue, May 02, 2017 at 09:39:34AM -0700, Alexander Duyck wrote:
>> >> On Mon, May 1,
On Tue, May 2, 2017 at 9:53 AM, Raj, Ashok wrote:
> On Tue, May 02, 2017 at 09:39:34AM -0700, Alexander Duyck wrote:
>> On Mon, May 1, 2017 at 4:13 PM, Casey Leedom wrote:
>> > The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed
>> > Ordering Attr
On Mon, May 1, 2017 at 4:13 PM, Casey Leedom wrote:
> The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed
> Ordering Attribute should not be used on Transaction Layer Packets destined
> for the PCIe End Node so flagged. Initially flagged this way are Intel
> E5-26xx Root Com
On Wed, Apr 26, 2017 at 2:26 AM, Ding Tianhong wrote:
> Hi Amir:
>
> It is really glad to hear that the mlx5 will support RO mode this year, if
> so, do you agree that enable it dynamic by ethtool -s xxx,
> we have try it several month ago but there was only one drivers would use it
> at that ti
On Tue, Apr 25, 2017 at 8:39 AM, Lino Sanfilippo wrote:
> Hi,
>
>> This patch doesn't look right to me. I would suggest rejecting it.
>>
>> The call to initialize the stats should be done when the ring is
>> allocated, not in ixgbe_probe(). This should probably be done in
>> ixgbe_alloc_q_vector()
On Mon, Apr 24, 2017 at 4:00 PM, Singh, Krishneil K
wrote:
>
>
>
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Liwei Song
> Sent: Sunday, December 4, 2016 7:41 PM
> To: Kirsher, Jeffrey T
> Cc: netdev@vger.kernel.org; intel-
On Fri, Apr 21, 2017 at 10:33 AM, Vladislav Yasevich
wrote:
> On Fri, Apr 21, 2017 at 1:33 AM, Michal Kubecek wrote:
>> On Thu, Apr 20, 2017 at 07:19:55PM -0400, Vlad Yasevich wrote:
>>>
>>> Having said that, the other alternative is to inherit hw_features from
>>> lower devices. BTW, bonding I
On Fri, Apr 21, 2017 at 7:20 AM, Jakub Kicinski
wrote:
> DMA unmap may destroy changes CPU made to the buffer. To make XDP
> run correctly on non-x86 platforms we should use the
> DMA_ATTR_SKIP_CPU_SYNC attribute.
>
> Thanks to using the attribute we can now push the sync operation to
> the commo
On Thu, Apr 20, 2017 at 4:19 PM, Vlad Yasevich wrote:
> On 04/20/2017 06:31 PM, Alexander Duyck wrote:
>> On Thu, Apr 20, 2017 at 12:17 PM, Vladislav Yasevich
>> wrote:
>>> While hardware device use either NETIF_F_(IP|IPV6)_CSUM or
>>> NETIF_F_HW_CSUM, all of
nstance
but you would still end up advertising checksum offload via HW_CSUM.
> CC: Michal Kubecek
> CC: Alexander Duyck
> CC: Tom Herbert
> Signed-off-by: Vladislav Yasevich
>
> ---
>
> V2: Addressed comments from Alex Duyck. I tested this with hacked virtio
> devi
On Wed, Apr 19, 2017 at 6:12 PM, Vladislav Yasevich wrote:
> While hardware device use either NETIF_F_(IP|IPV6)_CSUM or
> NETIF_F_HW_CSUM, all of the software devices use HW_CSUM.
> This results in an interesting situation when the software
> device is configured on top of hw device using (IP|IPV6
On Wed, Mar 29, 2017 at 5:22 PM, Sridhar Samudrala
wrote:
> In switchdev mode, broadcasts from VFs are received by the PF and passed
> to corresponding port representor netdev.
> Any frames sent via port netdevs are sent as directed transmits to the
> corresponding VFs. To enable directed transmit
On Fri, Apr 14, 2017 at 9:19 AM, Ben Greear wrote:
>
>
> On 04/14/2017 08:45 AM, Alexander Duyck wrote:
>>
>> On Thu, Apr 13, 2017 at 11:12 AM, Ben Greear
>> wrote:
>>>
>>> Hello,
>>>
>>> I have been seeing a regular occurrence
On Thu, Apr 13, 2017 at 11:12 AM, Ben Greear wrote:
> Hello,
>
> I have been seeing a regular occurrence of DMAR errors, looking something
> like this when testing my ath10k driver/firmware under some specific loads
> (maximum receive of 512 byte frames in AP mode):
>
> DMAR: DRHD: handling fault
On Mon, Apr 3, 2017 at 1:15 AM, Steffen Klassert
wrote:
> All available gso_type flags are currently in use, so
> extend gso_type from 'unsigned short' to 'unsigned int'
> to be able to add further flags.
>
> We also reorder the struct skb_shared_info to use
> two bytes of the four byte hole befor
On Thu, Apr 6, 2017 at 11:38 PM, Or Gerlitz wrote:
> On Fri, Apr 7, 2017 at 6:23 AM, Jeff Kirsher
> wrote:
>> From: Preethi Banala
>>
>> This patch adds a capability negotiation between VF and PF using ENCAP/
>> ENCAP_CSUM offload flags in order for the VF to support outer checksum
>> and TSO of
On Tue, Apr 4, 2017 at 10:16 AM, Duyck, Alexander H
wrote:
>> -Original Message-
>> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
>> Behalf Of Corinna Vinschen
>> Sent: Tuesday, April 4, 2017 8:11 AM
>> To: intel-wired-...@lists.osuosl.org
>> Cc: netdev@vger.ke
On Tue, Apr 4, 2017 at 4:58 AM, Or Gerlitz wrote:
> On Mon, Apr 3, 2017 at 9:41 PM, Samudrala, Sridhar
> wrote:
>> On 3/30/2017 12:17 AM, Or Gerlitz wrote:
>>> On Thu, Mar 30, 2017, Sridhar Samudrala wrote:
>
Port Representator netdevs are created for each PF and VF if the switch
mode i
On Thu, Mar 30, 2017 at 2:45 PM, Jakub Kicinski
wrote:
> On Wed, 29 Mar 2017 17:22:55 -0700, Sridhar Samudrala wrote:
>> Introduce switchdev_ops to PF and port netdevs to return the switch id via
>> SWITCHDEV_ATTR_ID_PORT_PARENT_ID attribute.
>> Also, ndo_get_phys_port_name() support is added to p
From: Alexander Duyck
While working on some recent busy poll changes we found that child sockets
were being instantiated without NAPI ID being set. In our first attempt to
fix it, it was suggested that we should just pull programming the NAPI ID
into the function itself since all callers will
From: Alexander Duyck
>From what I can tell there is only a couple spots where we are actually
checking the return value of sk_busy_loop. As there are only a few
consumers of that data, and the data being checked for can be replaced
with a check for !skb_queue_empty() we might as well just p
From: Alexander Duyck
This patch is a cleanup/fix for NAPI IDs following the changes that made it
so that sender_cpu and napi_id were doing a better job of sharing the same
location in the sk_buff.
One issue I found is that we weren't validating the napi_id as being valid
before we st
represents a sender_cpu then the value is ignored
and 0 is returned.
Signed-off-by: Sridhar Samudrala
Signed-off-by: Alexander Duyck
Acked-by: Eric Dumazet
---
arch/alpha/include/uapi/asm/socket.h |2 ++
arch/avr32/include/uapi/asm/socket.h |2 ++
arch/frv/include/uapi/asm/socket.h
From: Sridhar Samudrala
Move the core functionality in sk_busy_loop() to napi_busy_loop() and
make it independent of sk.
This enables re-using this function in epoll busy loop implementation.
Signed-off-by: Sridhar Samudrala
Signed-off-by: Alexander Duyck
Acked-by: Eric Dumazet
---
include
only sockets that receive packets from a single queue. So when an
application calls epoll_wait() and there are no events available to report,
busy polling is done on the associated queue to pull the packets.
Signed-off-by: Sridhar Samudrala
Signed-off-by: Alexander Duyck
---
fs/eventpoll.c |
From: Alexander Duyck
This patch flips the logic we were using to determine if the busy polling
has timed out. The main motivation for this is that we will need to
support two different possible timeout values in the future and by
recording the start time rather than when we would want to end
From: Alexander Duyck
Instead of defining two versions of skb_mark_napi_id I think it is more
readable to just match the format of the sk_mark_napi_id functions and just
wrap the contents of the function instead of defining two versions of the
function. This way we can save a few lines of code
ways reset to 0.
Added "Acked-by" for patches that received acks.
---
Alexander Duyck (5):
net: Busy polling should ignore sender CPUs
tcp: Record Rx hash and NAPI ID in tcp_child_process
net: Only define skb_mark_napi_id in one spot instead of two
net: C
From: Alexander Duyck
This change basically codifies what I think was already the limitations on
the busy_poll and busy_read sysctl interfaces. We weren't checking the
lower bounds and as such could input negative values. The behavior when
that was used was dependent on the architectur
On Fri, Mar 24, 2017 at 4:16 AM, Eric Dumazet wrote:
> On Thu, 2017-03-23 at 22:55 -0700, Alexander Duyck wrote:
>
>> Right, but time_after assumes roll over. When you are using a time
>> value based off of local_clock() >> 10, you don't ever roll over when
>&g
On Thu, Mar 23, 2017 at 9:27 PM, Eric Dumazet wrote:
> On Thu, 2017-03-23 at 20:42 -0700, Alexander Duyck wrote:
>> On Thu, Mar 23, 2017 at 6:24 PM, Eric Dumazet wrote:
>> > On Thu, 2017-03-23 at 14:37 -0700, Alexander Duyck wrote:
>> >> From: Alexander Duyck
&
On Thu, Mar 23, 2017 at 6:24 PM, Eric Dumazet wrote:
> On Thu, 2017-03-23 at 14:37 -0700, Alexander Duyck wrote:
>> From: Alexander Duyck
>>
>
>> The last bit I changed is to move from using a shift by 10 to just using
>> NSEC_PER_USEC and using multiplication for
On Thu, Mar 23, 2017 at 3:43 PM, Andy Lutomirski wrote:
> On Thu, Mar 23, 2017 at 2:38 PM, Alexander Duyck
> wrote:
>> From: Sridhar Samudrala
>>
>> This socket option returns the NAPI ID associated with the queue on which
>> the last frame is received. This infor
On Thu, Mar 23, 2017 at 3:07 PM, Alexei Starovoitov
wrote:
> On Thu, Mar 23, 2017 at 02:36:29PM -0700, Alexander Duyck wrote:
>> This is my second pass at trying to add support for busy polling when using
>> epoll. It is pretty much a full rewrite as I have made serious changes to
From: Sridhar Samudrala
Move the core functionality in sk_busy_loop() to napi_busy_loop() and
make it independent of sk.
This enables re-using this function in epoll busy loop implementation.
Signed-off-by: Sridhar Samudrala
Signed-off-by: Alexander Duyck
---
include/net/busy_poll.h | 20
ast 3 patches which enable epoll support
and add support for obtaining the NAPI ID of a given socket. With these
It becomes possible for an application to make use of epoll and get optimal
busy poll utilization by stacking multiple sockets with the same NAPI ID on
the same epoll context.
---
Alex
represents a sender_cpu then the value is ignored
and 0 is returned.
Signed-off-by: Sridhar Samudrala
Signed-off-by: Alexander Duyck
---
arch/alpha/include/uapi/asm/socket.h |2 ++
arch/avr32/include/uapi/asm/socket.h |2 ++
arch/frv/include/uapi/asm/socket.h |2 ++
arch/ia64/include
only sockets that receive packets from a single queue. So when an
application calls epoll_wait() and there are no events available to report,
busy polling is done on the associated queue to pull the packets.
Signed-off-by: Sridhar Samudrala
Signed-off-by: Alexander Duyck
---
fs/eventpoll.c |
From: Alexander Duyck
This patch flips the logic we were using to determine if the busy polling
has timed out. The main motivation for this is that we will need to
support two different possible timeout values in the future and by
recording the start time rather than when we would want to end
From: Alexander Duyck
>From what I can tell there is only a couple spots where we are actually
checking the return value of sk_busy_loop. As there are only a few
consumers of that data, and the data being checked for can be replaced
with a check for !skb_queue_empty() we might as well just p
From: Alexander Duyck
Instead of defining two versions of skb_mark_napi_id I think it is more
readable to just match the format of the sk_mark_napi_id functions and just
wrap the contents of the function instead of defining two versions of the
function. This way we can save a few lines of code
From: Alexander Duyck
This patch is a cleanup/fix for NAPI IDs following the changes that made it
so that sender_cpu and napi_id were doing a better job of sharing the same
location in the sk_buff.
One issue I found is that we weren't validating the napi_id as being valid
before we st
From: Alexander Duyck
While working on some recent busy poll changes we found that child sockets
were being instantiated without NAPI ID being set. In our first attempt to
fix it, it was suggested that we should just pull programming the NAPI ID
into the function itself since all callers will
a received patcket, but not recording the hash or NAPI ID of the packet
that was used to instanciate them.
---
Alexander Duyck (2):
net: Busy polling should ignore sender CPUs
tcp: Record Rx hash and NAPI ID in tcp_child_process
include/net/busy_poll.h | 11 +--
net/core
From: Alexander Duyck
This patch is a cleanup/fix for NAPI IDs following the changes that made it
so that sender_cpu and napi_id were doing a better job of sharing the same
location in the sk_buff.
One issue I found is that we weren't validating the napi_id as being valid
before we st
From: Alexander Duyck
While working on some recent busy poll changes we found that child sockets
were being instantiated without NAPI ID being set. In our first attempt to
fix it, it was suggested that we should just pull programming the NAPI ID
into the function itself since all callers will
tgen from a separate machine. Stock pktgen isn't good at
> reporting
> received pkts last I checked, so it may be more difficult to easily view the
> problem.
>
> I'll be happy to set up my tool on your Fedora 24 or similar VM or machine
> if you
> want.
>
>
On Thu, Mar 16, 2017 at 7:57 PM, Eric Dumazet wrote:
> On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote:
>
>> What I probably can do is go through and replace all the spots where
>> we where checking for sk_napi_id being 0, and instead replace it with
>> a check a
On Thu, Mar 16, 2017 at 3:50 PM, Eric Dumazet wrote:
> On Thu, 2017-03-16 at 15:33 -0700, Alexander Duyck wrote:
>> On Thu, Mar 16, 2017 at 3:05 PM, Eric Dumazet wrote:
>
>> > It is not clear why this patch is needed .
>> >
>> > What you describe here is
Can you include the pktgen script you are running?
Also when you say you are driving traffic through the bridge are you
sending from something external on the system or are you actually
directing the traffic from pktgen into the bridge directly?
- Alex
On Thu, Mar 16, 2017 at 3:49 PM, Ben Greear
On Thu, Mar 16, 2017 at 3:05 PM, Eric Dumazet wrote:
> On Thu, 2017-03-16 at 11:32 -0700, Alexander Duyck wrote:
>> From: Sridhar Samudrala
>>
>> Fix sk_mark_napi_id() and sk_mark_napi_id_once() to set sk_napi_id only if
>> skb->napi_id is a valid value.
>&g
On Thu, Mar 16, 2017 at 3:11 PM, Eric Dumazet wrote:
> On Thu, 2017-03-16 at 11:33 -0700, Alexander Duyck wrote:
>> From: Sridhar Samudrala
>
>> +/*
>> + * If busy polling is on and the file is a socket, return a pointer to
>> + * struct sock
>>
On Thu, Mar 16, 2017 at 3:04 PM, Eric Dumazet wrote:
> On Thu, 2017-03-16 at 11:32 -0700, Alexander Duyck wrote:
>> From: Sridhar Samudrala
>>
>> Call sk_mark_napi_id() in the ACK receive path of a TCP_NEW_SYN_RECV
>> socket, so that sk->napi_id is set even if
Signed-off-by: Alexander Duyck
---
net/ipv4/tcp_ipv4.c |1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 08d870e45658..b86002a296f1 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1687,6 +1687,7 @@ int tcp_v4_rcv(struct sk_b
This patch series is meant to add busy polling support to epoll when all of
the sockets on a given epoll are either local or are being sourced by the
same NAPI ID.
In order to support this the first two patches clean up a few issues we
found with the NAPI ID tracking and infrastructure.
In the th
Signed-off-by: Alexander Duyck
---
include/net/busy_poll.h |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h
index c0452de83086..67991635953e 100644
--- a/include/net/busy_poll.h
+++ b/include/net/busy_poll.h
@@ -116,7
Signed-off-by: Alexander Duyck
---
arch/alpha/include/uapi/asm/socket.h |2 ++
arch/avr32/include/uapi/asm/socket.h |2 ++
arch/frv/include/uapi/asm/socket.h |2 ++
arch/ia64/include/uapi/asm/socket.h|2 ++
arch/m32r/include/uapi/asm/socket.h|2 ++
arch/mips
From: Sridhar Samudrala
Move the core functionality in sk_busy_loop() to napi_busy_loop() and
make it independent of sk.
This enables re-using this function in epoll busy loop implementation.
Signed-off-by: Sridhar Samudrala
Signed-off-by: Alexander Duyck
---
include/net/busy_poll.h |9
associated queue to pull the packets.
Signed-off-by: Sridhar Samudrala
Signed-off-by: Alexander Duyck
---
fs/eventpoll.c | 115
1 file changed, 114 insertions(+), 1 deletion(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 341251421ced
lso provides a means for the device driver to return the level
supported for the offload type via the qopt->hw value. Previously we were
just always assuming the value to be 1, in the future values beyond just 1
may be supported.
Signed-off-by: Amritha Nambiar
Signed-off-by: Alexander Duyck
--
From: Alexander Duyck
This patch is meant to allow for support of multiple hardware offload type
for a single device. There is currently no bounds checking for the hw
member of the mqprio_qopt structure. This results in us being able to pass
values from 1 to 255 with all being treated the same
ivers that don't
support this can just fall back to their legacy configuration.
---
Alexander Duyck (1):
mqprio: Change handling of hw u8 to allow for multiple hardware offload
modes
Amritha Nambiar (1):
mqprio: Modify mqprio to pass user parameters via ndo_setup_tc.
drivers/n
801 - 900 of 1940 matches
Mail list logo
