* Re: [RFC PATCH v2 net-next 2/7] tcp: Merge tx_flags/tskey/txstamp_ack in tcp_collapse_retrans
From: Soheil Hassas Yeganeh @ 2016-04-19 18:24 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Eric Dumazet, netdev, Neal Cardwell, Soheil Hassas Yeganeh,
Willem de Bruijn, Yuchung Cheng, Kernel Team
In-Reply-To: <20160419181644.GA40600@kafai-mba.local>
On Tue, Apr 19, 2016 at 2:18 PM, Martin KaFai Lau <kafai@fb.com> wrote:
> On Tue, Apr 19, 2016 at 10:35:52AM -0700, Eric Dumazet wrote:
>> On Tue, Apr 19, 2016 at 10:28 AM, Martin KaFai Lau <kafai@fb.com> wrote:
>>
>> > A bit off topic, I feel like the SKBTX_ACK_TSTAMP and txstamp_ack are sort
>> > of redundant but I have not look into the details yet, so not completely
>> > sure. It wwould be a separate cleanup patch if it is the case.
>>
>> Please read 6b084928baac562ed61866f540a96120e9c9ddb7 changelog ;)
>>
>> A cache line miss avoidance is critical
> I looked at the patch but I probably am missing something :(
> Is checking txstamp_ack alone enough and SKBTX_ACK_TSTAMP is not needed
> since they are always set together?
That's right, the check on "(shinfo->tx_flags & SKBTX_ACK_TSTAMP)" in
tcp_ack_tstamp() is redundant and I had a patch prepared to remove it.
But I thought it's better to wait for
https://patchwork.ozlabs.org/patch/611938/ to be merged first.
Feel free to remove it in your patches, if you'd prefer that.
^ permalink raw reply
* Re: [PATCH net-next V2 05/11] net/mlx5e: Support RX multi-packet WQE (Striding RQ)
From: Saeed Mahameed @ 2016-04-19 18:30 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Eric Dumazet, Saeed Mahameed, David S. Miller, Linux Netdev List,
Or Gerlitz, Tal Alon, Tariq Toukan, Eran Ben Elisha,
Achiad Shochat, Mel Gorman, linux-mm
In-Reply-To: <20160419182532.423d3c05@redhat.com>
On Tue, Apr 19, 2016 at 7:25 PM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
> On Mon, 18 Apr 2016 07:17:13 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> Another idea would be to have a way to control max number of order-5
>> pages that a port would be using.
>>
>> Since driver always own a ref on a order-5 pages, idea would be to
>> maintain a circular ring of up to XXX such pages, so that we can detect
>> an abnormal use and fallback to order-0 immediately.
>
> That is part of my idea with my page-pool proposal. In the page-pool I
> want to have some watermark counter that can block/stop the OOM issue at
> this RX ring level.
>
> See slide 12 of presentation:
> http://people.netfilter.org/hawk/presentations/MM-summit2016/generic_page_pool_mm_summit2016.pdf
>
Cool Idea guys, and we already tested our own version of it,
we tried to recycle our own driver pages but we saw that the stack
took too long to release them, we had to work with 2X and sometimes 4X
pages pool per ring to be able to reuse recycled pages on every RX
packet on 50Gb line rate, but we dropped the Idea since 2X is too
much.
but definitely, this is the best way to go for all drivers, reusing
already dma mapped pages and significantly reducing dma operations for
the driver is a big win !
we are still considering such option as future optimization.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net-next v5] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: David Miller @ 2016-04-19 18:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: roopa, netdev, jhs, tgraf, nicolas.dichtel
In-Reply-To: <20160419.010316.1863885429013017239.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 19 Apr 2016 01:03:16 -0400 (EDT)
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 18 Apr 2016 21:32:04 -0700
>
>> On Mon, 2016-04-18 at 23:41 -0400, David Miller wrote:
>>>
>>> + /* Add a zero length NOP attribute so that the nla_data()
>>> + * of the IFLA_STATS64 will be 64-bit aligned.
>>> + */
>>> +#ifndef HAVE_EFFICIENT_UNALIGNED_ACCESS
>>> + attr = nla_reserve(skb, IFLA_PAD, 0);
>>> + if (!attr)
>>> + return -EMSGSIZE;
>>> +#endif
>>
>> You must do this only if current skb->data alignment is not correct.
>
> I'll put an assertion there if it makes you happy. :-)
Actually, you are right, as usual.
Here is the final patch I'm about to push out, thanks a lot Eric.
Roopa, please adjust your GETSTATS patch as needed (I think you need
to adjust the SELinux table entry as well) and we can integrate that
too.
====================
[PATCH] net: Align IFLA_STATS64 attributes properly on architectures that need it.
Since the nlattr header is 4 bytes in size, it can cause the netlink
attribute payload to not be 8-byte aligned.
This is particularly troublesome for IFLA_STATS64 which contains 64-bit
statistic values.
Solve this by creating a dummy IFLA_PAD attribute which has a payload
which is zero bytes in size. When HAVE_EFFICIENT_UNALIGNED_ACCESS is
false, we insert an IFLA_PAD attribute into the netlink response when
necessary such that the IFLA_STATS64 payload will be properly aligned.
With help and suggestions from Eric Dumazet.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/uapi/linux/if_link.h | 1 +
net/core/rtnetlink.c | 19 +++++++++++++++++++
2 files changed, 20 insertions(+)
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index bb3a90b..5ffdcb3 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -155,6 +155,7 @@ enum {
IFLA_PROTO_DOWN,
IFLA_GSO_MAX_SEGS,
IFLA_GSO_MAX_SIZE,
+ IFLA_PAD,
__IFLA_MAX
};
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index a7a3d34..198ca2c 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -878,6 +878,9 @@ static noinline size_t if_nlmsg_size(const struct net_device *dev,
+ nla_total_size(IFNAMSIZ) /* IFLA_QDISC */
+ nla_total_size(sizeof(struct rtnl_link_ifmap))
+ nla_total_size(sizeof(struct rtnl_link_stats))
+#ifndef HAVE_EFFICIENT_UNALIGNED_ACCESS
+ + nla_total_size(0) /* IFLA_PAD */
+#endif
+ nla_total_size(sizeof(struct rtnl_link_stats64))
+ nla_total_size(MAX_ADDR_LEN) /* IFLA_ADDRESS */
+ nla_total_size(MAX_ADDR_LEN) /* IFLA_BROADCAST */
@@ -1052,6 +1055,22 @@ static noinline_for_stack int rtnl_fill_stats(struct sk_buff *skb,
struct rtnl_link_stats64 *sp;
struct nlattr *attr;
+#ifndef HAVE_EFFICIENT_UNALIGNED_ACCESS
+ /* IF necessary, add a zero length NOP attribute so that the
+ * nla_data() of the IFLA_STATS64 will be 64-bit aligned.
+ *
+ * The nlattr header is 4 bytes in size, that's why we test
+ * if the skb->data _is_ aligned. This NOP attribute, plus
+ * nlattr header for IFLA_STATS64, will make nla_data() 8-byte
+ * aligned.
+ */
+ if (IS_ALIGNED((unsigned long)skb->data, 8)) {
+ attr = nla_reserve(skb, IFLA_PAD, 0);
+ if (!attr)
+ return -EMSGSIZE;
+ }
+#endif
+
attr = nla_reserve(skb, IFLA_STATS64,
sizeof(struct rtnl_link_stats64));
if (!attr)
--
2.4.1
^ permalink raw reply related
* RE: [Intel-wired-lan] i40e error handling LLDP messages from Arista switches
From: Parikh, Neerav @ 2016-04-19 18:31 UTC (permalink / raw)
To: Jeremy Ashton; +Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org
In-Reply-To: <CAH9ADKW4cse2v88xwOisr__R5w-O7siTMhAa2eUAUWK1hUtt9Q@mail.gmail.com>
> -----Original Message-----
> From: Jeremy Ashton [mailto:jeremy.ashton@shopify.com]
> Sent: Tuesday, April 19, 2016 11:10 AM
> To: Parikh, Neerav <neerav.parikh@intel.com>
> Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org
> Subject: Re: [Intel-wired-lan] i40e error handling LLDP messages from Arista
> switches
>
> So, what commands exactly are you looking to have run? Would packet
> capture of the lldp traffic help?
>
LLDP is running in the i40e device firmware so unless you've a packet capture on
the wire (Xgig) you may not see that in the wireshark/tshark on the host system.
The debugfs commands I was referring to below can help capture some
information; and for that you may need to mount the debugfs file system on
your setup. If debugfs is supported then once you've that mounted and have the
i40e driver loaded then you may see an entry named "i40e" under the mount point.
Assuming debugfs is mounted on /sys/kernel/debug the i40e directory will be under
/sys/kernel/debug/i40e. This directory will have entry for each PCIe device being
managed by the i40e driver. You can select the PCIe device that maps to the device
in question and can run the commands like:
echo "dump port" > /sys/kernel/debug/i40e/<pci-path>/command
echo "lldp get local" > /sys/kernel/debug/i40e/<pci-path>/command
echo "lldp get remote" > /sys/kernel/debug/i40e/<pci-path>/command
The output of these commands will show up in the dmesg log.
One another I noticed in your thread on the PF_RING bz is that you're using inbox
Ubuntu driver. Have you tried with current upstream and seen this issue?
Thanks,
Neerav
> On Tue, Apr 19, 2016 at 1:53 PM, Parikh, Neerav <neerav.parikh@intel.com>
> wrote:
> > Resending as the original email was sent in HTLM format and hence my reply
> went in that format
> > as well; which got rejected by netdev mailer.
> >
> >> -----Original Message-----
> >> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@lists.osuosl.org] On
> Behalf Of Parikh, Neerav
> >> Sent: Tuesday, April 19, 2016 10:45 AM
> >> To: Jeremy Ashton <jeremy.ashton@shopify.com>
> >> Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org
> >> Subject: Re: [Intel-wired-lan] i40e error handling LLDP messages from Arista
> switches
> >>
> >> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@lists.osuosl.org] On
> Behalf Of Jeremy Ashton
> >> > Sent: Tuesday, April 19, 2016 10:26 AM
> >> > Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org
> >> > Subject: [Intel-wired-lan] i40e error handling LLDP messages from Arista
> switches
> >> >
> >> > I have been trying to get pf_ring with zc running on ubuntu 14.04. The
> thread can be found here:
> >> >
> >> > https://github.com/ntop/PF_RING/issues/81
> >> >
> >> > Unfortunately it seems there is a bug in i40e which is carried into the code
> base for i40e_zc.
> >> >
> >> > $ modinfo i40e
> >> > filename: /lib/modules/3.19.0-58-
> generic/kernel/drivers/net/ethernet/intel/i40e/i40e.ko
> >> > version: 1.2.2-k
> >> > license: GPL
> >> > description: Intel(R) Ethernet Connection XL710 Network Driver
> >> > author: Intel Corporation, <e1000-devel@lists.sourceforge.net>
> >> > srcversion: E3DEEE00F49BBFBB8FF33A7
> >> > alias: pci:v00008086d00001586sv*sd*bc*sc*i*
> >> > alias: pci:v00008086d00001585sv*sd*bc*sc*i*
> >> > alias: pci:v00008086d00001584sv*sd*bc*sc*i*
> >> > alias: pci:v00008086d00001583sv*sd*bc*sc*i*
> >> > alias: pci:v00008086d00001581sv*sd*bc*sc*i*
> >> > alias: pci:v00008086d00001580sv*sd*bc*sc*i*
> >> > alias: pci:v00008086d0000157Fsv*sd*bc*sc*i*
> >> > alias: pci:v00008086d00001574sv*sd*bc*sc*i*
> >> > alias: pci:v00008086d00001572sv*sd*bc*sc*i*
> >> > depends: ptp,vxlan
> >> > intree: Y
> >> > vermagic: 3.19.0-58-generic SMP mod_unload modversions
> >> > signer: Magrathea: Glacier signing key
> >> > sig_key:
> DE:B3:43:0A:26:E6:7D:3D:3B:54:B9:DD:13:25:B3:3A:46:B2:F2:DD
> >> > sig_hashalgo: sha512
> >> > part: debug:Debug level (0=none,...,16=all) (int)
> >> >
> >> >
> >> > I wonder if someone might offer some insight as to the next steps to
> debug/resolve this.
> >> >
> >> > Cheers.
> >> >
> >> > Can you send us the dmesg output after running i40e debugfs commands
> >> > viz. “dump port”, “llpd get local” , “lldp get remote”, for the port that is
> showing
> >> > this behavior? Also, do you happen to know what is the Arista side
> configuration?
> >> > This will help us debug better.
> >> >
> >> > Thanks,
> >> > Neerav
^ permalink raw reply
* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Sinan Kaya @ 2016-04-19 18:37 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-rdma, timur, cov, Yishai Hadas, netdev, linux-kernel
In-Reply-To: <20160419182212.GA8441@infradead.org>
On 4/19/2016 2:22 PM, Christoph Hellwig wrote:
> What I think we need is something like the patch below. In the long
> ru nwe should also kill the mlx4_buf structure which now is pretty
> pointless.
Maybe; this could be the correct approach if we can guarantee that the
architecture can allocate the requested amount of memory with
dma_alloc_coherent.
When I brought this issue a year ago, the objection was that my code
doesn't compile on intel (dma_to_phys) and also some arches run out of
DMA memory with existing customer base.
If there is a real need to maintain compatibility with the existing
architectures due to limited amount of DMA memory, we need to correct this
code to make proper use of vmap via alloc_pages and also insert the
dma_sync in proper places for DMA API conformance.
Also, the tx descriptors always has to be allocated from a single DMA region
or the tx code needs to be corrected to support page_list.
If we can live with just using dma_alloc_coherent, your solution is
better. I was trying to put this support for 64bit arches only while
maintaining support for the existing code base.
>
> ---
> From a493881d2a6c90152d3daabb7b6b3afd1d254d78 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Tue, 19 Apr 2016 14:12:14 -0400
> Subject: mlx4_en: don't try to split and vmap dma coherent allocations
>
> The memory returned by dma_alloc_coherent is not suitable for calling
> virt_to_page on it, as it might for example come from vmap allocator.
>
> Remove the code that calls virt_to_page and vmap on dma coherent
> allocations from the mlx4 drivers, and replace them with a single
> high-order dma_alloc_coherent call.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Reported-by: Sinan Kaya <okaya@codeaurora.org>
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [RFC PATCH net-next 7/8] net: ipv4: listified version of ip_rcv
From: Tom Herbert @ 2016-04-19 18:38 UTC (permalink / raw)
To: Edward Cree
Cc: Eric Dumazet, Linux Kernel Network Developers, David Miller,
Jesper Dangaard Brouer, linux-net-drivers
In-Reply-To: <57166719.4070209@solarflare.com>
On Tue, Apr 19, 2016 at 10:12 AM, Edward Cree <ecree@solarflare.com> wrote:
> On 19/04/16 16:46, Tom Herbert wrote:
>> On Tue, Apr 19, 2016 at 7:50 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> We have hard time to deal with latencies already, and maintaining some
>>> sanity in the stack(s)
>> Right, this is significant complexity for a fairly narrow use case.
> Why do you say the use case is narrow? This approach should increase
> packet rate for any (non-GROed) traffic, whether for local delivery or
> forwarding. If you're line-rate limited, it'll save CPU time instead.
> The only reason I focused my testing on single-byte UDP is because the
> benefits are more easily measured in that case.
>
It's a narrow use case because of the intent to "suggested that having
multiple packets traverse the network stack together". Beyond queuing
to the backlog I don't understand what more processing can be done
without splitting the list up. We need to do a route lookup on each
packet, need to run each through IP tables, need to deliver each
packet individually to the application. For the queuing to backlog
that seems to me to be more of a localized bulk enqueue/dequeue
problem instead of a stack level infrastructure problem.
The general alternative to grouping packets together is to apply
cached values that were found in lookups for previous "similar"
packets. Since nearly all traffic fits some profile of a flow, we can
leverage the point that packets in a flow should have similar lookup
results. So, for example, the first time we see a flow we can create a
flow state and save any results of lookups found for that packets in
the flow (route lookup, IP tables etc.). For subsequent packets, if we
match the flow then we have the answers for all the lookups we would
need. Maintaining temporal flow states and performing fixed 5-tuple
flow state lookups in the hash table is easy for a host (and we can
often throw a lot of memory at it to size hash tables to avoid
collisions). VLP matching, open ended rule chains, multi table
lookups, crazy hashes over 35 fields in headers are the things we only
want to do when there is no other recourse. This illustrates one
reason why a host is not a switch, we have no hardware to do complex
lookups.
Tom
> If anything, the use case is broader than GRO, because GRO can't be used
> for datagram protocols where packet boundaries must be maintained.
> And because the listified processing is at least partly sharing code with
> the regular stack, it's less complexity than GRO which has to have
> essentially its own receive stack, _and_ code to coalesce the results
> back into a superframe.
>
> I think if we pushed bundled RX all the way up to the TCP layer, it might
> potentially also be faster than GRO, because it avoids the work of
> coalescing superframes; plus going through the GRO callbacks for each
> packet could end up blowing icache in the same way the regular stack does.
> If bundling did prove faster, we could then remove GRO, and overall
> complexity would be _reduced_.
>
> But I admit it may be a long shot.
>
> -Ed
^ permalink raw reply
* Re: [PATCH v2 1/1] drivers: net: cpsw: Prevent NUll pointer dereference with two PHYs
From: Grygorii Strashko @ 2016-04-19 18:44 UTC (permalink / raw)
To: David Rivshin (Allworx), David S. Miller
Cc: Andrew Goodbody, netdev, linux-kernel, linux-omap, mugunthanvnm,
tony
In-Reply-To: <20160419131443.7a3b3ef7.drivshin.allworx@gmail.com>
On 04/19/2016 08:14 PM, David Rivshin (Allworx) wrote:
> On Tue, 19 Apr 2016 18:44:41 +0300
> Grygorii Strashko <grygorii.strashko@ti.com> wrote:
>
>> On 04/19/2016 06:01 PM, David Rivshin (Allworx) wrote:
>>> On Tue, 19 Apr 2016 17:41:07 +0300
>>> Grygorii Strashko <grygorii.strashko@ti.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 04/19/2016 04:56 PM, Andrew Goodbody wrote:
>>>>> Adding a 2nd PHY to cpsw results in a NULL pointer dereference
>>>>> as below. Fix by maintaining a reference to each PHY node in slave
>>>>> struct instead of a single reference in the priv struct which was
>>>>> overwritten by the 2nd PHY.
>>>>
>>>> David, Is it possible to drop prev version of this patch from linux-next
>>>> - it breaks boot on many TI boards with -next.
>>>>
>>>>
>>>>>
>>>>> [ 17.870933] Unable to handle kernel NULL pointer dereference at virtual address 00000180
>>>>> [ 17.879557] pgd = dc8bc000
>>>>> [ 17.882514] [00000180] *pgd=9c882831, *pte=00000000, *ppte=00000000
>>>>> [ 17.889213] Internal error: Oops: 17 [#1] ARM
>>>>> [ 17.893838] Modules linked in:
>>>>> [ 17.897102] CPU: 0 PID: 1657 Comm: connmand Not tainted 4.5.0-ge463dfb-dirty #11
>>>>> [ 17.904947] Hardware name: Cambrionix whippet
>>>>> [ 17.909576] task: dc859240 ti: dc968000 task.ti: dc968000
>>>>> [ 17.915339] PC is at phy_attached_print+0x18/0x8c
>>>>> [ 17.920339] LR is at phy_attached_info+0x14/0x18
>>>>> [ 17.925247] pc : [<c042baec>] lr : [<c042bb74>] psr: 600f0113
>>>>> [ 17.925247] sp : dc969cf8 ip : dc969d28 fp : dc969d18
>>>>> [ 17.937425] r10: dda7a400 r9 : 00000000 r8 : 00000000
>>>>> [ 17.942971] r7 : 00000001 r6 : ddb00480 r5 : ddb8cb34 r4 : 00000000
>>>>> [ 17.949898] r3 : c0954cc0 r2 : c09562b0 r1 : 00000000 r0 : 00000000
>>>>> [ 17.956829] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
>>>>> [ 17.964401] Control: 10c5387d Table: 9c8bc019 DAC: 00000051
>>>>> [ 17.970500] Process connmand (pid: 1657, stack limit = 0xdc968210)
>>>>> [ 17.977059] Stack: (0xdc969cf8 to 0xdc96a000)
>>>>
>>>> [...]
>>>>
>>>>> [ 18.323956] [<c05e4cb8>] (inet_ioctl) from [<c055f5ac>] (sock_ioctl+0x15c/0x2d8)
>>>>> [ 18.331829] [<c055f450>] (sock_ioctl) from [<c010b388>] (do_vfs_ioctl+0x98/0x8d0)
>>>>> [ 18.339765] r7:00008914 r6:dc8ab4c0 r5:dd257ae0 r4:beaeda20
>>>>> [ 18.345822] [<c010b2f0>] (do_vfs_ioctl) from [<c010bc34>] (SyS_ioctl+0x74/0x84)
>>>>> [ 18.353573] r10:00000000 r9:00000011 r8:beaeda20 r7:00008914 r6:dc8ab4c0 r5:dc8ab4c0
>>>>> [ 18.361924] r4:00000000
>>>>> [ 18.364653] [<c010bbc0>] (SyS_ioctl) from [<c00163e0>] (ret_fast_syscall+0x0/0x3c)
>>>>> [ 18.372682] r9:dc968000 r8:c00165e8 r7:00000036 r6:00000002 r5:00000011 r4:00000000
>>>>> [ 18.380960] Code: e92dd810 e24cb010 e24dd010 e59b4004 (e5902180)
>>>>> [ 18.387580] ---[ end trace c80529466223f3f3 ]---
>>>>
>>>> ^ Could you make it shorter and drop timestamps, pls?
>>>>
>>>>>
>>>>> Signed-off-by: Andrew Goodbody <andrew.goodbody@cambrionix.com>
>>>>> ---
>>>>>
>>>>> v2 - Move allocation of memory for priv->slaves to inside cpsw_probe_dt so it
>>>>> has data->slaves initialised first which is needed to calculate size
>>>>>
>>>>> drivers/net/ethernet/ti/cpsw.c | 30 +++++++++++++++---------------
>>>>> 1 file changed, 15 insertions(+), 15 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
>>>>> index 42fdfd4..e62909c 100644
>>>>> --- a/drivers/net/ethernet/ti/cpsw.c
>>>>> +++ b/drivers/net/ethernet/ti/cpsw.c
>>>>> @@ -349,6 +349,7 @@ struct cpsw_slave {
>>>>> struct cpsw_slave_data *data;
>>>>> struct phy_device *phy;
>>>>> struct net_device *ndev;
>>>>> + struct device_node *phy_node;
>>>>> u32 port_vlan;
>>>>> u32 open_stat;
>>>>> };
>>>>> @@ -367,7 +368,6 @@ struct cpsw_priv {
>>>>> spinlock_t lock;
>>>>> struct platform_device *pdev;
>>>>> struct net_device *ndev;
>>>>> - struct device_node *phy_node;
>>>>> struct napi_struct napi_rx;
>>>>> struct napi_struct napi_tx;
>>>>> struct device *dev;
>>>>> @@ -1148,8 +1148,8 @@ static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
>>>>> cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast,
>>>>> 1 << slave_port, 0, 0, ALE_MCAST_FWD_2);
>>>>>
>>>>> - if (priv->phy_node)
>>>>> - slave->phy = of_phy_connect(priv->ndev, priv->phy_node,
>>>>> + if (slave->phy_node)
>>>>> + slave->phy = of_phy_connect(priv->ndev, slave->phy_node,
>>>>> &cpsw_adjust_link, 0, slave->data->phy_if);
>>>>> else
>>>>> slave->phy = phy_connect(priv->ndev, slave->data->phy_id,
>>>>> @@ -1946,7 +1946,7 @@ static int cpsw_probe_dt(struct cpsw_priv *priv,
>>>>> struct device_node *node = pdev->dev.of_node;
>>>>> struct device_node *slave_node;
>>>>> struct cpsw_platform_data *data = &priv->data;
>>>>> - int i = 0, ret;
>>>>> + int i, ret;
>>>>> u32 prop;
>>>>>
>>>>> if (!node)
>>>>> @@ -1958,6 +1958,14 @@ static int cpsw_probe_dt(struct cpsw_priv *priv,
>>>>> }
>>>>> data->slaves = prop;
>>>>>
>>>>> + priv->slaves = devm_kzalloc(&pdev->dev,
>>>>> + sizeof(struct cpsw_slave) * data->slaves,
>>>>> + GFP_KERNEL);
>>>>> + if (!priv->slaves)
>>>>> + return -ENOMEM;
>>>>> + for (i = 0; i < data->slaves; i++)
>>>>> + priv->slaves[i].slave_num = i;
>>>>> +
>>>>> if (of_property_read_u32(node, "active_slave", &prop)) {
>>>>> dev_err(&pdev->dev, "Missing active_slave property in the DT.\n");
>>>>> return -EINVAL;
>>>>> @@ -2023,6 +2031,7 @@ static int cpsw_probe_dt(struct cpsw_priv *priv,
>>>>> if (ret)
>>>>> dev_warn(&pdev->dev, "Doesn't have any child node\n");
>>>>>
>>>>> + i = 0;
>>>>> for_each_child_of_node(node, slave_node) {
>>>>> struct cpsw_slave_data *slave_data = data->slave_data + i;
>>>>> const void *mac_addr = NULL;
>>>>> @@ -2033,7 +2042,8 @@ static int cpsw_probe_dt(struct cpsw_priv *priv,
>>>>> if (strcmp(slave_node->name, "slave"))
>>>>> continue;
>>>>>
>>>>> - priv->phy_node = of_parse_phandle(slave_node, "phy-handle", 0);
>>>>> + priv->slaves[i].phy_node =
>>>>> + of_parse_phandle(slave_node, "phy-handle", 0);
>>>>
>>>> i++?
>>>>
>>>> Ideally, the simplest way is to save phy_node in slave_data, but ...
>>>> (see comment below).
>>>
>>> FYI, I have a patch [1] that does exactly that in my queue. Sorry
>>> I've been busy and haven't had a chance to rebase/retest/resubmit
>>> since Nicolas gave his Tested-By (and I missed Andrew's original
>>> patch). I can probably steal some time to resurrect that quickly
>>> if it's preferred, just let me know.
>>>
>>> [1] http://www.spinics.net/lists/netdev/msg357772.html
>>
>> Ah Ok. There are no user of cpsw_platform_data outside of net/ethernet/ti/,
>> so yes, looks like your patch 1 does exactly what's needed.
>
> Given that the v1 of Andrew's patch is already in Dave's net tree, and
> would obviously have many conflicts with mine, how should I proceed?
> Since you already requested Dave revert that patch, should I just wait
> for that to happen and then resubmit my series?
>
> Dave, Does that sound good to you?
>
May be you can send revert + your patch 1 (only fix for this issue).
Dave, Does that sound good to you?
--
regards,
-grygorii
^ permalink raw reply
* Re: [PATCH net-next v5] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: Eric Dumazet @ 2016-04-19 18:45 UTC (permalink / raw)
To: David Miller; +Cc: roopa, netdev, jhs, tgraf, nicolas.dichtel
In-Reply-To: <20160419.143134.2014460805657420897.davem@davemloft.net>
On Tue, 2016-04-19 at 14:31 -0400, David Miller wrote:
>
> Here is the final patch I'm about to push out, thanks a lot Eric.
>
> Roopa, please adjust your GETSTATS patch as needed (I think you need
> to adjust the SELinux table entry as well) and we can integrate that
> too.
>
> ====================
> [PATCH] net: Align IFLA_STATS64 attributes properly on architectures that need it.
>
> Since the nlattr header is 4 bytes in size, it can cause the netlink
> attribute payload to not be 8-byte aligned.
>
> This is particularly troublesome for IFLA_STATS64 which contains 64-bit
> statistic values.
>
> Solve this by creating a dummy IFLA_PAD attribute which has a payload
> which is zero bytes in size. When HAVE_EFFICIENT_UNALIGNED_ACCESS is
> false, we insert an IFLA_PAD attribute into the netlink response when
> necessary such that the IFLA_STATS64 payload will be properly aligned.
>
> With help and suggestions from Eric Dumazet.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> include/uapi/linux/if_link.h | 1 +
> net/core/rtnetlink.c | 19 +++++++++++++++++++
> 2 files changed, 20 insertions(+)
LGTM, thanks David ;)
^ permalink raw reply
* Re: [PATCHv2] wlcore: spi: add wl18xx support
From: Mark Brown @ 2016-04-19 18:46 UTC (permalink / raw)
To: Reizer, Eyal
Cc: kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
���� �����,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <us0dopt1inbrt0x47njgc2vy.1461089085965-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 524 bytes --]
On Tue, Apr 19, 2016 at 06:04:49PM +0000, Reizer, Eyal wrote:
> Thanks! Glad the illustration helped.
> I will try it out again as if i recall cotrectly, i did try that l, and it didnt produce the correct waveform, but perhaps i didnt understand the usage of .cs_change correctly.
> Will double check anyway.
It could also be a bug in your controller driver, it's common for them
to not handle cs_change correctly (at least those that open code the
message loop, obviously modern ones just factor this out into the core).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v5] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: Eric Dumazet @ 2016-04-19 18:47 UTC (permalink / raw)
To: David Miller; +Cc: roopa, netdev, jhs, tgraf, nicolas.dichtel
In-Reply-To: <20160419.143134.2014460805657420897.davem@davemloft.net>
On Tue, 2016-04-19 at 14:31 -0400, David Miller wrote:
> +#ifndef HAVE_EFFICIENT_UNALIGNED_ACCESS
> + /* IF necessary, add a zero length NOP attribute so that the
> + * nla_data() of the IFLA_STATS64 will be 64-bit aligned.
> + *
> + * The nlattr header is 4 bytes in size, that's why we test
> + * if the skb->data _is_ aligned. This NOP attribute, plus
> + * nlattr header for IFLA_STATS64, will make nla_data() 8-byte
> + * aligned.
> + */
> + if (IS_ALIGNED((unsigned long)skb->data, 8)) {
> + attr = nla_reserve(skb, IFLA_PAD, 0);
> + if (!attr)
> + return -EMSGSIZE;
> + }
> +#endif
Since we want to use this in other places, we could define a helper.
nla_align_64bit(skb, attribute) or something.
^ permalink raw reply
* Re: [PATCH net-next v5] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: Roopa Prabhu @ 2016-04-19 19:05 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, jhs, tgraf, nicolas.dichtel
In-Reply-To: <20160419.143134.2014460805657420897.davem@davemloft.net>
On 4/19/16, 11:31 AM, David Miller wrote:
[snip]
>
> Here is the final patch I'm about to push out, thanks a lot Eric.
>
> Roopa, please adjust your GETSTATS patch as needed (I think you need
> to adjust the SELinux table entry as well) and we can integrate that
> too.
ok, will do. one thing though, for GETSTATS, if I need a pad attribute like IFLA_PAD,
I will need to add a new stats attribute IFLA_STATS_PAD and burn a bit for it in filter_mask too.
In which case, I am wondering if we should live with the copy. I will take any suggestions here.
I had adjusted the SELinux table entries for v5. I will check again and make sure it is right for v6.
>
> ====================
> [PATCH] net: Align IFLA_STATS64 attributes properly on architectures that need it.
>
> Since the nlattr header is 4 bytes in size, it can cause the netlink
> attribute payload to not be 8-byte aligned.
>
> This is particularly troublesome for IFLA_STATS64 which contains 64-bit
> statistic values.
>
> Solve this by creating a dummy IFLA_PAD attribute which has a payload
> which is zero bytes in size. When HAVE_EFFICIENT_UNALIGNED_ACCESS is
> false, we insert an IFLA_PAD attribute into the netlink response when
> necessary such that the IFLA_STATS64 payload will be properly aligned.
>
> With help and suggestions from Eric Dumazet.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
[snip]
Thanks David.
^ permalink raw reply
* [RFC PATCH 0/5] Add GSO Partial support for devices with existing tunnel offloads
From: Alexander Duyck @ 2016-04-19 19:05 UTC (permalink / raw)
To: eugenia, bruce.w.allan, saeedm, netdev, intel-wired-lan,
ariel.elior, mchan
This patch set is meant to extend tunnel offload support for devices that
already support UDP or GRE tunnels to include support for those type of
tunnels with an outer checksum. To do this I am enabling GSO partial
support for these types of tunnels which should work assuming the devices
supported by these drivers are either overwriting or ignoring checksum and
length fields contained in the IPv4/v6 and ignoring the checksum contained
in the outer L4 tunnel headers.
I don't have any of the hardware that uses the drivers that these patches
are applied do. That was one of the motivations for submitting them as RFC.
My hope is that somebody out there with this hardware is willing to pull in
the patch and test it out in order to determine if this approach actually
works for these devices.
---
Alexander Duyck (5):
mlx4: Add support for UDP tunnel segmentation with outer checksum offload
mlx5: Add support for UDP tunnel segmentation with outer checksum offload
bnx2x: Add support for segmentation of tunnels with outer checksums
bnxt: Add support for segmentation of tunnels with outer checksums
fm10k: Add support for UDP tunnel segmentation with outer checksum offload
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 13 ++++++++++---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 9 +++++++--
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 14 ++++++++++----
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 17 +++++++++++++----
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 7 ++++++-
5 files changed, 46 insertions(+), 14 deletions(-)
^ permalink raw reply
* [RFC PATCH 1/5] mlx4: Add support for UDP tunnel segmentation with outer checksum offload
From: Alexander Duyck @ 2016-04-19 19:05 UTC (permalink / raw)
To: eugenia, bruce.w.allan, saeedm, netdev, intel-wired-lan,
ariel.elior, mchan
In-Reply-To: <20160419185949.11723.50506.stgit@ahduyck-xeon-server>
This patch assumes that the mlx4 hardware will ignore existing IPv4/v6
header fields for length and checksum as well as the length and checksum
fields for outer UDP headers.
I have no means of testing this as I do not have any mlx4 hardware but
thought I would submit it as an RFC to see if anyone out there wants to
test this and see if this does in fact enable this functionality allowing
us to to segment UDP tunneled frames that have an outer checksum.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index b4b258c8ca47..cb6a8a522857 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -2356,7 +2356,9 @@ out:
/* set offloads */
priv->dev->hw_enc_features |= NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
- NETIF_F_TSO | NETIF_F_GSO_UDP_TUNNEL;
+ NETIF_F_TSO | NETIF_F_GSO_UDP_TUNNEL |
+ NETIF_F_GSO_UDP_TUNNEL_CSUM |
+ NETIF_F_GSO_PARTIAL;
}
static void mlx4_en_del_vxlan_offloads(struct work_struct *work)
@@ -2366,7 +2368,9 @@ static void mlx4_en_del_vxlan_offloads(struct work_struct *work)
vxlan_del_task);
/* unset offloads */
priv->dev->hw_enc_features &= ~(NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
- NETIF_F_TSO | NETIF_F_GSO_UDP_TUNNEL);
+ NETIF_F_TSO | NETIF_F_GSO_UDP_TUNNEL |
+ NETIF_F_GSO_UDP_TUNNEL_CSUM |
+ NETIF_F_GSO_PARTIAL);
ret = mlx4_SET_PORT_VXLAN(priv->mdev->dev, priv->port,
VXLAN_STEER_BY_OUTER_MAC, 0);
@@ -2990,8 +2994,13 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
}
if (mdev->dev->caps.tunnel_offload_mode == MLX4_TUNNEL_OFFLOAD_MODE_VXLAN) {
- dev->hw_features |= NETIF_F_GSO_UDP_TUNNEL;
- dev->features |= NETIF_F_GSO_UDP_TUNNEL;
+ dev->hw_features |= NETIF_F_GSO_UDP_TUNNEL |
+ NETIF_F_GSO_UDP_TUNNEL_CSUM |
+ NETIF_F_GSO_PARTIAL;
+ dev->features |= NETIF_F_GSO_UDP_TUNNEL |
+ NETIF_F_GSO_UDP_TUNNEL_CSUM |
+ NETIF_F_GSO_PARTIAL;
+ dev->gso_partial_features = NETIF_F_GSO_UDP_TUNNEL_CSUM;
}
mdev->pndev[port] = dev;
^ permalink raw reply related
* [RFC PATCH 2/5] mlx5: Add support for UDP tunnel segmentation with outer checksum offload
From: Alexander Duyck @ 2016-04-19 19:06 UTC (permalink / raw)
To: eugenia, bruce.w.allan, saeedm, netdev, intel-wired-lan,
ariel.elior, mchan
In-Reply-To: <20160419185949.11723.50506.stgit@ahduyck-xeon-server>
This patch assumes that the mlx5 hardware will ignore existing IPv4/v6
header fields for length and checksum as well as the length and checksum
fields for outer UDP headers.
I have no means of testing this as I do not have any mlx5 hardware but
thought I would submit it as an RFC to see if anyone out there wants to
test this and see if this does in fact enable this functionality allowing
us to to segment UDP tunneled frames that have an outer checksum.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index e0adb604f461..57d8da796d50 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -2390,13 +2390,18 @@ static void mlx5e_build_netdev(struct net_device *netdev)
netdev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER;
if (mlx5e_vxlan_allowed(mdev)) {
- netdev->hw_features |= NETIF_F_GSO_UDP_TUNNEL;
+ netdev->hw_features |= NETIF_F_GSO_UDP_TUNNEL |
+ NETIF_F_GSO_UDP_TUNNEL_CSUM |
+ NETIF_F_GSO_PARTIAL;
netdev->hw_enc_features |= NETIF_F_IP_CSUM;
netdev->hw_enc_features |= NETIF_F_RXCSUM;
netdev->hw_enc_features |= NETIF_F_TSO;
netdev->hw_enc_features |= NETIF_F_TSO6;
netdev->hw_enc_features |= NETIF_F_RXHASH;
netdev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL;
+ netdev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL_CSUM |
+ NETIF_F_GSO_PARTIAL;
+ netdev->gso_partial_features = NETIF_F_GSO_UDP_TUNNEL_CSUM;
}
netdev->features = netdev->hw_features;
^ permalink raw reply related
* [RFC PATCH 3/5] bnx2x: Add support for segmentation of tunnels with outer checksums
From: Alexander Duyck @ 2016-04-19 19:06 UTC (permalink / raw)
To: eugenia, bruce.w.allan, saeedm, netdev, intel-wired-lan,
ariel.elior, mchan
In-Reply-To: <20160419185949.11723.50506.stgit@ahduyck-xeon-server>
This patch assumes that the bnx2x hardware will ignore existing IPv4/v6
header fields for length and checksum as well as the length and checksum
fields for outer UDP and GRE headers.
I have no means of testing this as I do not have any bnx2x hardware but
thought I would submit it as an RFC to see if anyone out there wants to
test this and see if this does in fact enable this functionality allowing
us to to segment tunneled frames that have an outer checksum.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index d465bd721146..e3459524fb0e 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13258,14 +13258,21 @@ static int bnx2x_init_dev(struct bnx2x *bp, struct pci_dev *pdev,
NETIF_F_RXCSUM | NETIF_F_LRO | NETIF_F_GRO |
NETIF_F_RXHASH | NETIF_F_HW_VLAN_CTAG_TX;
if (!chip_is_e1x) {
- dev->hw_features |= NETIF_F_GSO_GRE | NETIF_F_GSO_UDP_TUNNEL |
- NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT;
+ dev->hw_features |= NETIF_F_GSO_GRE | NETIF_F_GSO_GRE_CSUM |
+ NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT |
+ NETIF_F_GSO_UDP_TUNNEL |
+ NETIF_F_GSO_UDP_TUNNEL_CSUM |
+ NETIF_F_GSO_PARTIAL;
dev->hw_enc_features =
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_SG |
NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6 |
NETIF_F_GSO_IPIP |
NETIF_F_GSO_SIT |
- NETIF_F_GSO_GRE | NETIF_F_GSO_UDP_TUNNEL;
+ NETIF_F_GSO_GRE | NETIF_F_GSO_GRE_CSUM |
+ NETIF_F_GSO_UDP_TUNNEL | NETIF_F_GSO_UDP_TUNNEL_CSUM |
+ NETIF_F_GSO_PARTIAL;
+ dev->gso_partial_features = NETIF_F_GSO_GRE_CSUM |
+ NETIF_F_GSO_UDP_TUNNEL_CSUM;
}
dev->vlan_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
^ permalink raw reply related
* [RFC PATCH 4/5] bnxt: Add support for segmentation of tunnels with outer checksums
From: Alexander Duyck @ 2016-04-19 19:06 UTC (permalink / raw)
To: eugenia, bruce.w.allan, saeedm, netdev, intel-wired-lan,
ariel.elior, mchan
In-Reply-To: <20160419185949.11723.50506.stgit@ahduyck-xeon-server>
This patch assumes that the bnxt hardware will ignore existing IPv4/v6
header fields for length and checksum as well as the length and checksum
fields for outer UDP and GRE headers.
I have no means of testing this as I do not have any bnx2x hardware but
thought I would submit it as an RFC to see if anyone out there wants to
test this and see if this does in fact enable this functionality allowing
us to to segment tunneled frames that have an outer checksum.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 4645c44e7c15..ae668476fff0 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -6194,14 +6194,19 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
NETIF_F_TSO | NETIF_F_TSO6 |
NETIF_F_GSO_UDP_TUNNEL | NETIF_F_GSO_GRE |
NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT |
- NETIF_F_RXHASH |
+ NETIF_F_GSO_UDP_TUNNEL_CSUM | NETIF_F_GSO_GRE_CSUM |
+ NETIF_F_GSO_PARTIAL | NETIF_F_RXHASH |
NETIF_F_RXCSUM | NETIF_F_LRO | NETIF_F_GRO;
dev->hw_enc_features =
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_SG |
NETIF_F_TSO | NETIF_F_TSO6 |
NETIF_F_GSO_UDP_TUNNEL | NETIF_F_GSO_GRE |
- NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT;
+ NETIF_F_GSO_UDP_TUNNEL_CSUM | NETIF_F_GSO_GRE_CSUM |
+ NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT |
+ NETIF_F_GSO_PARTIAL;
+ dev->gso_partial_features = NETIF_F_GSO_UDP_TUNNEL_CSUM |
+ NETIF_F_GSO_GRE_CSUM;
dev->vlan_features = dev->hw_features | NETIF_F_HIGHDMA;
dev->hw_features |= NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_HW_VLAN_CTAG_TX |
NETIF_F_HW_VLAN_STAG_RX | NETIF_F_HW_VLAN_STAG_TX;
^ permalink raw reply related
* [RFC PATCH 5/5] fm10k: Add support for UDP tunnel segmentation with outer checksum offload
From: Alexander Duyck @ 2016-04-19 19:06 UTC (permalink / raw)
To: eugenia, bruce.w.allan, saeedm, netdev, intel-wired-lan,
ariel.elior, mchan
In-Reply-To: <20160419185949.11723.50506.stgit@ahduyck-xeon-server>
This patch assumes that the fm10k hardware will ignore existing IPv4/v6
header fields for length and checksum as well as the length and checksum
fields for outer UDP headers.
I have no means of testing this as I do not have any mlx5 hardware but
thought I would submit it as an RFC to see if anyone out there wants to
test this and see if this does in fact enable this functionality allowing
us to to segment UDP tunneled frames that have an outer checksum.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
index 2a08d3f5b6df..dc4901def72d 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
@@ -1417,15 +1417,21 @@ struct net_device *fm10k_alloc_netdev(const struct fm10k_info *info)
/* Only the PF can support VXLAN and NVGRE tunnel offloads */
if (info->mac == fm10k_mac_pf) {
- dev->hw_enc_features = NETIF_F_IP_CSUM |
+ dev->hw_enc_features = NETIF_F_SG |
+ NETIF_F_IP_CSUM |
+ NETIF_F_IPV6_CSUM |
NETIF_F_TSO |
NETIF_F_TSO6 |
NETIF_F_TSO_ECN |
NETIF_F_GSO_UDP_TUNNEL |
- NETIF_F_IPV6_CSUM |
- NETIF_F_SG;
+ NETIF_F_GSO_UDP_TUNNEL_CSUM |
+ NETIF_F_GSO_PARTIAL;
+
+ dev->features |= NETIF_F_GSO_UDP_TUNNEL |
+ NETIF_F_GSO_UDP_TUNNEL_CSUM |
+ NETIF_F_GSO_PARTIAL;
- dev->features |= NETIF_F_GSO_UDP_TUNNEL;
+ dev->gso_partial_features = NETIF_F_GSO_UDP_TUNNEL_CSUM;
}
/* all features defined to this point should be changeable */
^ permalink raw reply related
* Re: [PATCH net-next v5] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: Nicolas Dichtel @ 2016-04-19 19:08 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: roopa, netdev, jhs, tgraf
In-Reply-To: <1461091667.10638.229.camel@edumazet-glaptop3.roam.corp.google.com>
Le 19/04/2016 20:47, Eric Dumazet a écrit :
> On Tue, 2016-04-19 at 14:31 -0400, David Miller wrote:
>
>> +#ifndef HAVE_EFFICIENT_UNALIGNED_ACCESS
>> + /* IF necessary, add a zero length NOP attribute so that the
>> + * nla_data() of the IFLA_STATS64 will be 64-bit aligned.
>> + *
>> + * The nlattr header is 4 bytes in size, that's why we test
>> + * if the skb->data _is_ aligned. This NOP attribute, plus
>> + * nlattr header for IFLA_STATS64, will make nla_data() 8-byte
>> + * aligned.
>> + */
>> + if (IS_ALIGNED((unsigned long)skb->data, 8)) {
>> + attr = nla_reserve(skb, IFLA_PAD, 0);
>> + if (!attr)
>> + return -EMSGSIZE;
>> + }
>> +#endif
>
> Since we want to use this in other places, we could define a helper.
>
> nla_align_64bit(skb, attribute) or something.
Yes, with the corresponding nla_total_size_64bit()
^ permalink raw reply
* Re: [RFC PATCH net-next 0/8] Handle multiple received packets at each stage
From: Jesper Dangaard Brouer @ 2016-04-19 19:11 UTC (permalink / raw)
To: Edward Cree; +Cc: netdev, David Miller, linux-net-drivers, brouer
In-Reply-To: <5716338E.4050003@solarflare.com>
On Tue, 19 Apr 2016 14:33:02 +0100
Edward Cree <ecree@solarflare.com> wrote:
> Earlier discussions on this list[1] suggested that having multiple packets
> traverse the network stack together (rather than calling the stack for each
> packet singly) could improve performance through better cache locality.
> This patch series is an attempt to implement this by having drivers pass an
> SKB list to the stack at the end of the NAPI poll. The stack then attempts
> to keep the list together, only splitting it when either packets need to be
> treated differently, or the next layer of the stack is not list-aware.
>
> The first two patches simply place received packets on a list during the
> event processing loop on the sfc EF10 architecture, then call the normal
> stack for each packet singly at the end of the NAPI poll.
> The remaining patches extend the 'listified' processing as far as the IP
> receive handler.
>
> Packet rate was tested with NetPerf UDP_STREAM, with 10 streams of 1-byte
> packets, and the process and interrupt pinned to a single core on the RX
> side.
> The NIC was a 40G Solarflare 7x42Q; the CPU was a Xeon E3-1220V2 @ 3.10GHz.
> Baseline: 5.07Mpps
> after patch 2: 5.59Mpps (10.2% above baseline)
> after patch 8: 6.44Mpps (25.6% above baseline)
Quite impressive! Thank you Edward, for working on this. It is nice
to see that doing this actually gives a nice performance boost, it was
mostly a theory of mine in [1].
(p.s. I'm currently a bit busy at MM-summit, but try to follow the
thread. I want to try out your patchset once I return home again...)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
[1] http://thread.gmane.org/gmane.linux.network/395502
^ permalink raw reply
* Re: [PATCH net-next V4 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
From: Alexander Duyck @ 2016-04-19 19:11 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: olaf, Netdev, Jason Wang, linux-kernel@vger.kernel.org, jackm,
yevgenyp, John Ronciak, intel-wired-lan, eli, Robo Bot, devel,
David Miller
In-Reply-To: <1461096723-26471-2-git-send-email-kys@microsoft.com>
On Tue, Apr 19, 2016 at 1:12 PM, K. Y. Srinivasan <kys@microsoft.com> wrote:
> On Hyper-V, the VF/PF communication is a via software mediated path
> as opposed to the hardware mailbox. Make the necessary
> adjustments to support Hyper-V.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
> V2: Addressed most of the comments from
> Alexander Duyck <alexander.duyck@gmail.com>
> and Rustad, Mark D <mark.d.rustad@intel.com>.
>
> V3: Addressed additional comments from
> Alexander Duyck <alexander.duyck@gmail.com>
>
> V4: Addressed kbuild errors reported by:
> kbuild test robot <lkp@intel.com>
>
>
> drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 31 +++-
> drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++
> drivers/net/ethernet/intel/ixgbevf/vf.c | 216 +++++++++++++++++++++
> drivers/net/ethernet/intel/ixgbevf/vf.h | 2 +
> 5 files changed, 266 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> index 5ac60ee..3296d27 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> @@ -460,9 +460,13 @@ enum ixbgevf_state_t {
>
> enum ixgbevf_boards {
> board_82599_vf,
> + board_82599_vf_hv,
> board_X540_vf,
> + board_X540_vf_hv,
> board_X550_vf,
> + board_X550_vf_hv,
> board_X550EM_x_vf,
> + board_X550EM_x_vf_hv,
> };
>
> enum ixgbevf_xcast_modes {
> @@ -477,6 +481,13 @@ extern const struct ixgbevf_info ixgbevf_X550_vf_info;
> extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_info;
> extern const struct ixgbe_mbx_operations ixgbevf_mbx_ops;
>
> +
> +extern const struct ixgbevf_info ixgbevf_82599_vf_hv_info;
> +extern const struct ixgbevf_info ixgbevf_X540_vf_hv_info;
> +extern const struct ixgbevf_info ixgbevf_X550_vf_hv_info;
> +extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info;
> +extern const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops;
> +
> /* needed by ethtool.c */
> extern const char ixgbevf_driver_name[];
> extern const char ixgbevf_driver_version[];
> @@ -494,6 +505,7 @@ void ixgbevf_free_rx_resources(struct ixgbevf_ring *);
> void ixgbevf_free_tx_resources(struct ixgbevf_ring *);
> void ixgbevf_update_stats(struct ixgbevf_adapter *adapter);
> int ethtool_ioctl(struct ifreq *ifr);
> +bool ixgbevf_on_hyperv(struct ixgbe_hw *hw);
>
> extern void ixgbevf_write_eitr(struct ixgbevf_q_vector *q_vector);
>
> diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> index 007cbe0..c4bb480 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> @@ -62,10 +62,14 @@ static char ixgbevf_copyright[] =
> "Copyright (c) 2009 - 2015 Intel Corporation.";
>
> static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
> - [board_82599_vf] = &ixgbevf_82599_vf_info,
> - [board_X540_vf] = &ixgbevf_X540_vf_info,
> - [board_X550_vf] = &ixgbevf_X550_vf_info,
> - [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
> + [board_82599_vf] = &ixgbevf_82599_vf_info,
> + [board_82599_vf_hv] = &ixgbevf_82599_vf_hv_info,
> + [board_X540_vf] = &ixgbevf_X540_vf_info,
> + [board_X540_vf_hv] = &ixgbevf_X540_vf_hv_info,
> + [board_X550_vf] = &ixgbevf_X550_vf_info,
> + [board_X550_vf_hv] = &ixgbevf_X550_vf_hv_info,
> + [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
> + [board_X550EM_x_vf_hv] = &ixgbevf_X550EM_x_vf_hv_info,
> };
>
> /* ixgbevf_pci_tbl - PCI Device ID Table
> @@ -78,9 +82,13 @@ static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
> */
> static const struct pci_device_id ixgbevf_pci_tbl[] = {
> {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF), board_82599_vf },
> + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF_HV), board_82599_vf_hv },
> {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF), board_X540_vf },
> + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF_HV), board_X540_vf_hv },
> {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF), board_X550_vf },
> + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF_HV), board_X550_vf_hv },
> {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF), board_X550EM_x_vf },
> + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV), board_X550EM_x_vf_hv},
> /* required last entry */
> {0, }
> };
> @@ -1795,7 +1803,10 @@ static void ixgbevf_configure_rx(struct ixgbevf_adapter *adapter)
> ixgbevf_setup_vfmrqc(adapter);
>
> /* notify the PF of our intent to use this size of frame */
> - ixgbevf_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN + ETH_FCS_LEN);
> + if (!ixgbevf_on_hyperv(hw))
> + ixgbevf_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN + ETH_FCS_LEN);
> + else
> + ixgbevf_hv_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN + ETH_FCS_LEN);
>
> /* Setup the HW Rx Head and Tail Descriptor Pointers and
> * the Base and Length of the Rx Descriptor Ring
> @@ -2056,7 +2067,10 @@ static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
> spin_lock_bh(&adapter->mbx_lock);
>
> while (api[idx] != ixgbe_mbox_api_unknown) {
> - err = ixgbevf_negotiate_api_version(hw, api[idx]);
> + if (!ixgbevf_on_hyperv(hw))
> + err = ixgbevf_negotiate_api_version(hw, api[idx]);
> + else
> + err = ixgbevf_hv_negotiate_api_version(hw, api[idx]);
> if (!err)
> break;
> idx++;
> @@ -3727,7 +3741,10 @@ static int ixgbevf_change_mtu(struct net_device *netdev, int new_mtu)
> netdev->mtu = new_mtu;
>
> /* notify the PF of our intent to use this size of frame */
> - ixgbevf_rlpml_set_vf(hw, max_frame);
> + if (!ixgbevf_on_hyperv(hw))
> + ixgbevf_rlpml_set_vf(hw, max_frame);
> + else
> + ixgbevf_hv_rlpml_set_vf(hw, max_frame);
>
> return 0;
> }
> diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.c b/drivers/net/ethernet/intel/ixgbevf/mbx.c
> index dc68fea..298a0da 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/mbx.c
> +++ b/drivers/net/ethernet/intel/ixgbevf/mbx.c
> @@ -346,3 +346,15 @@ const struct ixgbe_mbx_operations ixgbevf_mbx_ops = {
> .check_for_rst = ixgbevf_check_for_rst_vf,
> };
>
> +/**
> + * Mailbox operations when running on Hyper-V.
> + * On Hyper-V, PF/VF communiction is not through the
> + * hardware mailbox; this communication is through
> + * a software mediated path.
> + * Most mail box operations are noop while running on
> + * Hyper-V.
> + */
> +const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops = {
> + .init_params = ixgbevf_init_mbx_params_vf,
> + .check_for_rst = ixgbevf_check_for_rst_vf,
> +};
> diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
> index 4d613a4..8f277b9 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/vf.c
> +++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
> @@ -27,6 +27,13 @@
> #include "vf.h"
> #include "ixgbevf.h"
>
> +/*
> + * On Hyper-V, to reset, we need to read from this offset
> + * from the PCI config space. This is the mechanism used on
> + * Hyper-V to support PF/VF communication.
> + */
> +#define IXGBE_HV_RESET_OFFSET 0x201
> +
> /**
> * ixgbevf_start_hw_vf - Prepare hardware for Tx/Rx
> * @hw: pointer to hardware structure
> @@ -126,6 +133,27 @@ static s32 ixgbevf_reset_hw_vf(struct ixgbe_hw *hw)
> }
>
> /**
> + * Hyper-V variant; the VF/PF communication is through the PCI
> + * config space.
> + */
> +static s32 ixgbevf_hv_reset_hw_vf(struct ixgbe_hw *hw)
> +{
> +#if IS_ENABLED(CONFIG_PCI_MMCONFIG)
> + struct ixgbevf_adapter *adapter = hw->back;
> + int i;
> +
> + for (i = 0; i < 6; i++)
> + pci_read_config_byte(adapter->pdev,
> + (i + IXGBE_HV_RESET_OFFSET),
> + &hw->mac.perm_addr[i]);
> +#else
> + pr_err("PCI_MMCONFIG needs to be enabled for Hyper-V\n");
> +#endif
> +
> + return 0;
> +}
> +
You should probably just return an error here if MMCONFIG is not
defined. You can probably move the return into the #if/#else blocks
so that you return 0 if MMCONFIG is supported, and you return
-EOPNOTSUPP if MMCONFIG is not defined.
That way you don't have to worry about confusing the driver and having
it think that it is running with no MAC address assigned by the
administrator.
- Alex
^ permalink raw reply
* Re: [PATCH net-next v5] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: Johannes Berg @ 2016-04-19 19:41 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, roopa, netdev, jhs, tgraf, nicolas.dichtel,
egrumbach
In-Reply-To: <20160419.142324.1774057494079734967.davem@davemloft.net>
On Tue, 2016-04-19 at 14:23 -0400, David Miller wrote:
>
> I like this nlattr flag idea, it's opt-in and any tool can be updated
> to use the new facility.
Right.
> I'd be willing the backport the nlattr flag bit change to all stable
> releases as well.
I'm not really convinced that helps much - tools still can't really
rely on the kernel supporting it.
One thing that might work is that a tool might say it only wants to
support kernels that have this change (assuming we backport it to
enough kernels etc.); in that case the tool could add some absolutely
must-have information (like the IFINDEX or whatever, depends on the
command) with the new flag, this would get rejected since unpatched
kernels wouldn't understand the flag and wouldn't find that must-have
information.
Nevertheless, I think it's most reliable with new netlink commands that
are known to be available only on kernels understand and treating the
flag correctly.
johannes
^ permalink raw reply
* Re: [PATCH net-next v5] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: Paul Moore @ 2016-04-19 19:55 UTC (permalink / raw)
To: nicolas.dichtel
Cc: Roopa Prabhu, netdev, jhs, davem, tgraf, Stephen Smalley,
Eric Paris
In-Reply-To: <5715EBCF.20801@6wind.com>
On Tue, Apr 19, 2016 at 4:26 AM, Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
> + selinux maintainers
>
> Le 18/04/2016 23:10, Roopa Prabhu a écrit :
> [snip]
>>
>> diff --git a/security/selinux/nlmsgtab.c b/security/selinux/nlmsgtab.c
>> index 8495b93..1714633 100644
>> --- a/security/selinux/nlmsgtab.c
>> +++ b/security/selinux/nlmsgtab.c
>> @@ -76,6 +76,8 @@ static struct nlmsg_perm nlmsg_route_perms[] =
>> { RTM_NEWNSID, NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
>> { RTM_DELNSID, NETLINK_ROUTE_SOCKET__NLMSG_READ },
>> { RTM_GETNSID, NETLINK_ROUTE_SOCKET__NLMSG_READ },
>> + { RTM_NEWSTATS, NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
>
> I would say it's NETLINK_ROUTE_SOCKET__NLMSG_READ, not WRITE. This command
> is only sent by the kernel, not by the userland.
From what I could tell from the patch description, it looks like
RTM_NEWSTATS only dumps stats to userspace and doesn't alter the state
of the kernel, is that correct? If so, then yes, NLMSG__READ is the
right SELinux permission. However, if RTM_NEWSTATS does alter the
state/configuration of the kernel then we should use NLMSG__WRITE.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* [PATCH net-next V4 0/2] ethernet: intel: Support Hyper-V hosts
From: K. Y. Srinivasan @ 2016-04-19 20:11 UTC (permalink / raw)
To: davem, netdev, linux-kernel, devel, olaf, apw, jasowang, eli,
jackm, yevgenyp, john.ronciak, intel-wired-lan, alexander.duyck
Make adjustments to the Intel 10G VF driver to support
running on Hyper-V hosts.
K. Y. Srinivasan (2):
ethernet: intel: Add the device ID's presented while running on
Hyper-V
intel: ixgbevf: Support Windows hosts (Hyper-V)
drivers/net/ethernet/intel/ixgbevf/defines.h | 5 +
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 31 +++-
drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++
drivers/net/ethernet/intel/ixgbevf/vf.c | 216 +++++++++++++++++++++
drivers/net/ethernet/intel/ixgbevf/vf.h | 2 +
6 files changed, 271 insertions(+), 7 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH net-next V4 1/2] ethernet: intel: Add the device ID's presented while running on Hyper-V
From: K. Y. Srinivasan @ 2016-04-19 20:12 UTC (permalink / raw)
To: davem, netdev, linux-kernel, devel, olaf, apw, jasowang, eli,
jackm, yevgenyp, john.ronciak, intel-wired-lan, alexander.duyck
In-Reply-To: <1461096698-26430-1-git-send-email-kys@microsoft.com>
Intel SR-IOV cards present different ID when running on Hyper-V.
Add the device IDs presented while running on Hyper-V.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
V4: No change from V1
drivers/net/ethernet/intel/ixgbevf/defines.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/defines.h b/drivers/net/ethernet/intel/ixgbevf/defines.h
index 5843458..1306a0d 100644
--- a/drivers/net/ethernet/intel/ixgbevf/defines.h
+++ b/drivers/net/ethernet/intel/ixgbevf/defines.h
@@ -33,6 +33,11 @@
#define IXGBE_DEV_ID_X550_VF 0x1565
#define IXGBE_DEV_ID_X550EM_X_VF 0x15A8
+#define IXGBE_DEV_ID_82599_VF_HV 0x152E
+#define IXGBE_DEV_ID_X540_VF_HV 0x1530
+#define IXGBE_DEV_ID_X550_VF_HV 0x1564
+#define IXGBE_DEV_ID_X550EM_X_VF_HV 0x15A9
+
#define IXGBE_VF_IRQ_CLEAR_MASK 7
#define IXGBE_VF_MAX_TX_QUEUES 8
#define IXGBE_VF_MAX_RX_QUEUES 8
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next V4 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
From: K. Y. Srinivasan @ 2016-04-19 20:12 UTC (permalink / raw)
To: davem, netdev, linux-kernel, devel, olaf, apw, jasowang, eli,
jackm, yevgenyp, john.ronciak, intel-wired-lan, alexander.duyck
In-Reply-To: <1461096723-26471-1-git-send-email-kys@microsoft.com>
On Hyper-V, the VF/PF communication is a via software mediated path
as opposed to the hardware mailbox. Make the necessary
adjustments to support Hyper-V.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
V2: Addressed most of the comments from
Alexander Duyck <alexander.duyck@gmail.com>
and Rustad, Mark D <mark.d.rustad@intel.com>.
V3: Addressed additional comments from
Alexander Duyck <alexander.duyck@gmail.com>
V4: Addressed kbuild errors reported by:
kbuild test robot <lkp@intel.com>
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 31 +++-
drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++
drivers/net/ethernet/intel/ixgbevf/vf.c | 216 +++++++++++++++++++++
drivers/net/ethernet/intel/ixgbevf/vf.h | 2 +
5 files changed, 266 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
index 5ac60ee..3296d27 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
@@ -460,9 +460,13 @@ enum ixbgevf_state_t {
enum ixgbevf_boards {
board_82599_vf,
+ board_82599_vf_hv,
board_X540_vf,
+ board_X540_vf_hv,
board_X550_vf,
+ board_X550_vf_hv,
board_X550EM_x_vf,
+ board_X550EM_x_vf_hv,
};
enum ixgbevf_xcast_modes {
@@ -477,6 +481,13 @@ extern const struct ixgbevf_info ixgbevf_X550_vf_info;
extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_info;
extern const struct ixgbe_mbx_operations ixgbevf_mbx_ops;
+
+extern const struct ixgbevf_info ixgbevf_82599_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X540_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X550_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info;
+extern const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops;
+
/* needed by ethtool.c */
extern const char ixgbevf_driver_name[];
extern const char ixgbevf_driver_version[];
@@ -494,6 +505,7 @@ void ixgbevf_free_rx_resources(struct ixgbevf_ring *);
void ixgbevf_free_tx_resources(struct ixgbevf_ring *);
void ixgbevf_update_stats(struct ixgbevf_adapter *adapter);
int ethtool_ioctl(struct ifreq *ifr);
+bool ixgbevf_on_hyperv(struct ixgbe_hw *hw);
extern void ixgbevf_write_eitr(struct ixgbevf_q_vector *q_vector);
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 007cbe0..c4bb480 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -62,10 +62,14 @@ static char ixgbevf_copyright[] =
"Copyright (c) 2009 - 2015 Intel Corporation.";
static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
- [board_82599_vf] = &ixgbevf_82599_vf_info,
- [board_X540_vf] = &ixgbevf_X540_vf_info,
- [board_X550_vf] = &ixgbevf_X550_vf_info,
- [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
+ [board_82599_vf] = &ixgbevf_82599_vf_info,
+ [board_82599_vf_hv] = &ixgbevf_82599_vf_hv_info,
+ [board_X540_vf] = &ixgbevf_X540_vf_info,
+ [board_X540_vf_hv] = &ixgbevf_X540_vf_hv_info,
+ [board_X550_vf] = &ixgbevf_X550_vf_info,
+ [board_X550_vf_hv] = &ixgbevf_X550_vf_hv_info,
+ [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
+ [board_X550EM_x_vf_hv] = &ixgbevf_X550EM_x_vf_hv_info,
};
/* ixgbevf_pci_tbl - PCI Device ID Table
@@ -78,9 +82,13 @@ static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
*/
static const struct pci_device_id ixgbevf_pci_tbl[] = {
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF), board_82599_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF_HV), board_82599_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF), board_X540_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF_HV), board_X540_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF), board_X550_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF_HV), board_X550_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF), board_X550EM_x_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV), board_X550EM_x_vf_hv},
/* required last entry */
{0, }
};
@@ -1795,7 +1803,10 @@ static void ixgbevf_configure_rx(struct ixgbevf_adapter *adapter)
ixgbevf_setup_vfmrqc(adapter);
/* notify the PF of our intent to use this size of frame */
- ixgbevf_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN + ETH_FCS_LEN);
+ if (!ixgbevf_on_hyperv(hw))
+ ixgbevf_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN + ETH_FCS_LEN);
+ else
+ ixgbevf_hv_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN + ETH_FCS_LEN);
/* Setup the HW Rx Head and Tail Descriptor Pointers and
* the Base and Length of the Rx Descriptor Ring
@@ -2056,7 +2067,10 @@ static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
spin_lock_bh(&adapter->mbx_lock);
while (api[idx] != ixgbe_mbox_api_unknown) {
- err = ixgbevf_negotiate_api_version(hw, api[idx]);
+ if (!ixgbevf_on_hyperv(hw))
+ err = ixgbevf_negotiate_api_version(hw, api[idx]);
+ else
+ err = ixgbevf_hv_negotiate_api_version(hw, api[idx]);
if (!err)
break;
idx++;
@@ -3727,7 +3741,10 @@ static int ixgbevf_change_mtu(struct net_device *netdev, int new_mtu)
netdev->mtu = new_mtu;
/* notify the PF of our intent to use this size of frame */
- ixgbevf_rlpml_set_vf(hw, max_frame);
+ if (!ixgbevf_on_hyperv(hw))
+ ixgbevf_rlpml_set_vf(hw, max_frame);
+ else
+ ixgbevf_hv_rlpml_set_vf(hw, max_frame);
return 0;
}
diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.c b/drivers/net/ethernet/intel/ixgbevf/mbx.c
index dc68fea..298a0da 100644
--- a/drivers/net/ethernet/intel/ixgbevf/mbx.c
+++ b/drivers/net/ethernet/intel/ixgbevf/mbx.c
@@ -346,3 +346,15 @@ const struct ixgbe_mbx_operations ixgbevf_mbx_ops = {
.check_for_rst = ixgbevf_check_for_rst_vf,
};
+/**
+ * Mailbox operations when running on Hyper-V.
+ * On Hyper-V, PF/VF communiction is not through the
+ * hardware mailbox; this communication is through
+ * a software mediated path.
+ * Most mail box operations are noop while running on
+ * Hyper-V.
+ */
+const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops = {
+ .init_params = ixgbevf_init_mbx_params_vf,
+ .check_for_rst = ixgbevf_check_for_rst_vf,
+};
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index 4d613a4..8f277b9 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -27,6 +27,13 @@
#include "vf.h"
#include "ixgbevf.h"
+/*
+ * On Hyper-V, to reset, we need to read from this offset
+ * from the PCI config space. This is the mechanism used on
+ * Hyper-V to support PF/VF communication.
+ */
+#define IXGBE_HV_RESET_OFFSET 0x201
+
/**
* ixgbevf_start_hw_vf - Prepare hardware for Tx/Rx
* @hw: pointer to hardware structure
@@ -126,6 +133,27 @@ static s32 ixgbevf_reset_hw_vf(struct ixgbe_hw *hw)
}
/**
+ * Hyper-V variant; the VF/PF communication is through the PCI
+ * config space.
+ */
+static s32 ixgbevf_hv_reset_hw_vf(struct ixgbe_hw *hw)
+{
+#if IS_ENABLED(CONFIG_PCI_MMCONFIG)
+ struct ixgbevf_adapter *adapter = hw->back;
+ int i;
+
+ for (i = 0; i < 6; i++)
+ pci_read_config_byte(adapter->pdev,
+ (i + IXGBE_HV_RESET_OFFSET),
+ &hw->mac.perm_addr[i]);
+#else
+ pr_err("PCI_MMCONFIG needs to be enabled for Hyper-V\n");
+#endif
+
+ return 0;
+}
+
+/**
* ixgbevf_stop_hw_vf - Generic stop Tx/Rx units
* @hw: pointer to hardware structure
*
@@ -258,6 +286,11 @@ static s32 ixgbevf_set_uc_addr_vf(struct ixgbe_hw *hw, u32 index, u8 *addr)
return ret_val;
}
+static s32 ixgbevf_hv_set_uc_addr_vf(struct ixgbe_hw *hw, u32 index, u8 *addr)
+{
+ return -EOPNOTSUPP;
+}
+
/**
* ixgbevf_get_reta_locked - get the RSS redirection table (RETA) contents.
* @adapter: pointer to the port handle
@@ -416,6 +449,26 @@ static s32 ixgbevf_set_rar_vf(struct ixgbe_hw *hw, u32 index, u8 *addr,
return ret_val;
}
+/**
+ * ixgbevf_hv_set_rar_vf - set device MAC address Hyper-V variant
+ * @hw: pointer to hardware structure
+ * @index: Receive address register to write
+ * @addr: Address to put into receive address register
+ * @vmdq: Unused in this implementation
+ *
+ * We don't really allow setting the device MAC address. However,
+ * if the address being set is the permanent MAC address we will
+ * permit that.
+ **/
+static s32 ixgbevf_hv_set_rar_vf(struct ixgbe_hw *hw, u32 index, u8 *addr,
+ u32 vmdq)
+{
+ if (ether_addr_equal(addr, hw->mac.perm_addr))
+ return 0;
+
+ return -EOPNOTSUPP;
+}
+
static void ixgbevf_write_msg_read_ack(struct ixgbe_hw *hw,
u32 *msg, u16 size)
{
@@ -473,6 +526,15 @@ static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
}
/**
+ * Hyper-V variant - just a stub.
+ */
+static s32 ixgbevf_hv_update_mc_addr_list_vf(struct ixgbe_hw *hw,
+ struct net_device *netdev)
+{
+ return -EOPNOTSUPP;
+}
+
+/**
* ixgbevf_update_xcast_mode - Update Multicast mode
* @hw: pointer to the HW structure
* @netdev: pointer to net device structure
@@ -513,6 +575,15 @@ static s32 ixgbevf_update_xcast_mode(struct ixgbe_hw *hw,
}
/**
+ * Hyper-V variant - just a stub.
+ */
+static s32 ixgbevf_hv_update_xcast_mode(struct ixgbe_hw *hw,
+ struct net_device *netdev, int xcast_mode)
+{
+ return -EOPNOTSUPP;
+}
+
+/**
* ixgbevf_set_vfta_vf - Set/Unset VLAN filter table address
* @hw: pointer to the HW structure
* @vlan: 12 bit VLAN ID
@@ -551,6 +622,15 @@ mbx_err:
}
/**
+ * Hyper-V variant - just a stub.
+ */
+static s32 ixgbevf_hv_set_vfta_vf(struct ixgbe_hw *hw, u32 vlan, u32 vind,
+ bool vlan_on)
+{
+ return -EOPNOTSUPP;
+}
+
+/**
* ixgbevf_setup_mac_link_vf - Setup MAC link settings
* @hw: pointer to hardware structure
* @speed: Unused in this implementation
@@ -656,6 +736,67 @@ out:
}
/**
+ * Hyper-V variant; there is no mailbox communication.
+ */
+static s32 ixgbevf_hv_check_mac_link_vf(struct ixgbe_hw *hw,
+ ixgbe_link_speed *speed,
+ bool *link_up,
+ bool autoneg_wait_to_complete)
+{
+ struct ixgbe_mbx_info *mbx = &hw->mbx;
+ struct ixgbe_mac_info *mac = &hw->mac;
+ u32 links_reg;
+
+ /* If we were hit with a reset drop the link */
+ if (!mbx->ops.check_for_rst(hw) || !mbx->timeout)
+ mac->get_link_status = true;
+
+ if (!mac->get_link_status)
+ goto out;
+
+ /* if link status is down no point in checking to see if pf is up */
+ links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
+ if (!(links_reg & IXGBE_LINKS_UP))
+ goto out;
+
+ /* for SFP+ modules and DA cables on 82599 it can take up to 500usecs
+ * before the link status is correct
+ */
+ if (mac->type == ixgbe_mac_82599_vf) {
+ int i;
+
+ for (i = 0; i < 5; i++) {
+ udelay(100);
+ links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
+
+ if (!(links_reg & IXGBE_LINKS_UP))
+ goto out;
+ }
+ }
+
+ switch (links_reg & IXGBE_LINKS_SPEED_82599) {
+ case IXGBE_LINKS_SPEED_10G_82599:
+ *speed = IXGBE_LINK_SPEED_10GB_FULL;
+ break;
+ case IXGBE_LINKS_SPEED_1G_82599:
+ *speed = IXGBE_LINK_SPEED_1GB_FULL;
+ break;
+ case IXGBE_LINKS_SPEED_100_82599:
+ *speed = IXGBE_LINK_SPEED_100_FULL;
+ break;
+ }
+
+ /* if we passed all the tests above then the link is up and we no
+ * longer need to check for link
+ */
+ mac->get_link_status = false;
+
+out:
+ *link_up = !mac->get_link_status;
+ return 0;
+}
+
+/**
* ixgbevf_rlpml_set_vf - Set the maximum receive packet length
* @hw: pointer to the HW structure
* @max_size: value to assign to max frame size
@@ -670,6 +811,25 @@ void ixgbevf_rlpml_set_vf(struct ixgbe_hw *hw, u16 max_size)
}
/**
+ * ixgbevf_hv_rlpml_set_vf - Set the maximum receive packet length
+ * @hw: pointer to the HW structure
+ * @max_size: value to assign to max frame size
+ * Hyper-V variant.
+ **/
+void ixgbevf_hv_rlpml_set_vf(struct ixgbe_hw *hw, u16 max_size)
+{
+ u32 reg;
+
+ /* If we are on Hyper-V, we implement
+ * this functionality differently.
+ */
+ reg = IXGBE_READ_REG(hw, IXGBE_VFRXDCTL(0));
+ /* CRC == 4 */
+ reg |= ((max_size + 4) | IXGBE_RXDCTL_RLPML_EN);
+ IXGBE_WRITE_REG(hw, IXGBE_VFRXDCTL(0), reg);
+}
+
+/**
* ixgbevf_negotiate_api_version - Negotiate supported API version
* @hw: pointer to the HW structure
* @api: integer containing requested API version
@@ -703,6 +863,22 @@ int ixgbevf_negotiate_api_version(struct ixgbe_hw *hw, int api)
return err;
}
+/**
+ * ixgbevf_hv_negotiate_api_version - Negotiate supported API version
+ * @hw: pointer to the HW structure
+ * @api: integer containing requested API version
+ * Hyper-V version - only ixgbe_mbox_api_10 supported.
+ **/
+int ixgbevf_hv_negotiate_api_version(struct ixgbe_hw *hw, int api)
+{
+ /* Hyper-V only supports api version ixgbe_mbox_api_10
+ */
+ if (api != ixgbe_mbox_api_10)
+ return IXGBE_ERR_INVALID_ARGUMENT;
+
+ return 0;
+}
+
int ixgbevf_get_queues(struct ixgbe_hw *hw, unsigned int *num_tcs,
unsigned int *default_tc)
{
@@ -776,22 +952,62 @@ static const struct ixgbe_mac_operations ixgbevf_mac_ops = {
.set_vfta = ixgbevf_set_vfta_vf,
};
+static const struct ixgbe_mac_operations ixgbevf_hv_mac_ops = {
+ .init_hw = ixgbevf_init_hw_vf,
+ .reset_hw = ixgbevf_hv_reset_hw_vf,
+ .start_hw = ixgbevf_start_hw_vf,
+ .get_mac_addr = ixgbevf_get_mac_addr_vf,
+ .stop_adapter = ixgbevf_stop_hw_vf,
+ .setup_link = ixgbevf_setup_mac_link_vf,
+ .check_link = ixgbevf_hv_check_mac_link_vf,
+ .set_rar = ixgbevf_hv_set_rar_vf,
+ .update_mc_addr_list = ixgbevf_hv_update_mc_addr_list_vf,
+ .update_xcast_mode = ixgbevf_hv_update_xcast_mode,
+ .set_uc_addr = ixgbevf_hv_set_uc_addr_vf,
+ .set_vfta = ixgbevf_hv_set_vfta_vf,
+};
+
const struct ixgbevf_info ixgbevf_82599_vf_info = {
.mac = ixgbe_mac_82599_vf,
.mac_ops = &ixgbevf_mac_ops,
};
+const struct ixgbevf_info ixgbevf_82599_vf_hv_info = {
+ .mac = ixgbe_mac_82599_vf,
+ .mac_ops = &ixgbevf_hv_mac_ops,
+};
+
const struct ixgbevf_info ixgbevf_X540_vf_info = {
.mac = ixgbe_mac_X540_vf,
.mac_ops = &ixgbevf_mac_ops,
};
+const struct ixgbevf_info ixgbevf_X540_vf_hv_info = {
+ .mac = ixgbe_mac_X540_vf,
+ .mac_ops = &ixgbevf_hv_mac_ops,
+};
+
const struct ixgbevf_info ixgbevf_X550_vf_info = {
.mac = ixgbe_mac_X550_vf,
.mac_ops = &ixgbevf_mac_ops,
};
+const struct ixgbevf_info ixgbevf_X550_vf_hv_info = {
+ .mac = ixgbe_mac_X550_vf,
+ .mac_ops = &ixgbevf_hv_mac_ops,
+};
+
const struct ixgbevf_info ixgbevf_X550EM_x_vf_info = {
.mac = ixgbe_mac_X550EM_x_vf,
.mac_ops = &ixgbevf_mac_ops,
};
+
+const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info = {
+ .mac = ixgbe_mac_X550EM_x_vf,
+ .mac_ops = &ixgbevf_hv_mac_ops,
+};
+
+bool ixgbevf_on_hyperv(struct ixgbe_hw *hw)
+{
+ return hw->mbx.ops.check_for_msg == NULL;
+}
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.h b/drivers/net/ethernet/intel/ixgbevf/vf.h
index ef9f773..658883e 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.h
@@ -208,7 +208,9 @@ static inline u32 ixgbe_read_reg_array(struct ixgbe_hw *hw, u32 reg,
#define IXGBE_READ_REG_ARRAY(h, r, o) ixgbe_read_reg_array(h, r, o)
void ixgbevf_rlpml_set_vf(struct ixgbe_hw *hw, u16 max_size);
+void ixgbevf_hv_rlpml_set_vf(struct ixgbe_hw *hw, u16 max_size);
int ixgbevf_negotiate_api_version(struct ixgbe_hw *hw, int api);
+int ixgbevf_hv_negotiate_api_version(struct ixgbe_hw *hw, int api);
int ixgbevf_get_queues(struct ixgbe_hw *hw, unsigned int *num_tcs,
unsigned int *default_tc);
int ixgbevf_get_reta_locked(struct ixgbe_hw *hw, u32 *reta, int num_rx_queues);
--
1.7.4.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox