* Re: [PATCH net-next] sctp: remove the old ttl expires policy
From: David Miller @ 2016-10-13 13:44 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, vyasevich, daniel
In-Reply-To: <db5df5806c3c0b7c37ab9039a906664a33c74563.1475898016.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 8 Oct 2016 11:40:16 +0800
> The prsctp polices include ttl expires policy already, we should remove
> the old ttl expires codes, and just adjust the new polices' codes to be
> compatible with the old one for users.
>
> This patch is to remove all the old expires codes, and if prsctp polices
> are not set, it will still set msg's expires_at and check the expires in
> sctp_check_abandoned.
>
> Note that asoc->prsctp_enable is set by default, so users can't feel any
> difference even if they use the old expires api in userspace.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sctp: reuse sent_count to avoid retransmitted chunks for RTT measurements
From: David Miller @ 2016-10-13 13:44 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, vyasevich, daniel
In-Reply-To: <b68194a4735a1ea5a652c13540df5d68e3c4b305.1475897765.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 8 Oct 2016 11:36:05 +0800
> Now sctp uses chunk->resent to record if a chunk is retransmitted, for
> RTT measurements with retransmitted DATA chunks. chunk->sent_count was
> introduced to record how many times one chunk has been sent for prsctp
> RTX policy before. We actually can know if one chunk is retransmitted
> by checking chunk->sent_count is greater than 1.
>
> This patch is to remove resent from sctp_chunk and reuse sent_count
> to avoid retransmitted chunks for RTT measurements.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Johannes Berg @ 2016-10-13 13:45 UTC (permalink / raw)
To: Sergey Senozhatsky, Andy Lutomirski
Cc: Andy Lutomirski, David S. Miller, Linux Wireless List,
Network Development, linux-kernel@vger.kernel.org,
Sergey Senozhatsky, linux-next@vger.kernel.org, Stephen Rothwell,
Herbert Xu
In-Reply-To: <20161013134252.GA583@swordfish>
On Thu, 2016-10-13 at 22:42 +0900, Sergey Senozhatsky wrote:
>
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > t/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > t/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
> >
> > That truly sounds like something we'd rather avoid in the TX/RX
> > paths though, which should perform well.
>
> didn't fix.
It couldn't, since the new helpers weren't used in mac80211 in those
patches yet.
> so I finally had some time to do a better bug-reporter job.
>
> I added a bunch of printk-s and several virt_addr_valid()-s
> to ieee80211_aes_ccm_encrypt().
>
> and right befoe the Oops I see the following report from
> virt_addr_valid()
>
>
> FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02
> >> 39) == 130
Yeah, we already know that in this function the aad variable is on the
stack, it explicitly is.
The question, though, is why precisely that fails in the crypto code.
Can you send the Oops report itself?
johannes
^ permalink raw reply
* Re: [PATCH] vmxnet3: avoid assumption about invalid dma_pa in vmxnet3_set_mc()
From: David Miller @ 2016-10-13 13:43 UTC (permalink / raw)
To: khoroshilov; +Cc: skhare, pv-drivers, netdev, linux-kernel, ldv-project
In-Reply-To: <1475895223-3225-1-git-send-email-khoroshilov@ispras.ru>
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date: Fri, 7 Oct 2016 22:53:43 -0400
> vmxnet3_set_mc() still assumes zero is invalid pa:
> it assumes dma_mapping_error(...,0) returns true if vmxnet3_copy_mc() fails;
> it calls dma_unmap_single() iff new_table_pa is not zero.
>
> The patch adds an explicit variable to track status of new_table_pa.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Please use "bool" and "true"/"false" for boolean variables.
Thanks.
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-13 13:42 UTC (permalink / raw)
To: Andy Lutomirski, Johannes Berg
Cc: Sergey Senozhatsky, Andy Lutomirski, David S. Miller,
Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <1476338524.4904.1.camel@sipsolutions.net>
On (10/13/16 08:02), Johannes Berg wrote:
> On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote:
>
> > In a pinch, I have these patches sitting around:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
>
> That truly sounds like something we'd rather avoid in the TX/RX paths
> though, which should perform well.
didn't fix.
so I finally had some time to do a better bug-reporter job.
I added a bunch of printk-s and several virt_addr_valid()-s
to ieee80211_aes_ccm_encrypt().
and right befoe the Oops I see the following report from
virt_addr_valid()
FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02 >> 39) == 130
which is basically failed '!phys_addr_valid(x)' in __virt_addr_valid()
/* carry flag will be set if starting x was >= PAGE_OFFSET */
if ((x > y) || !phys_addr_valid(x))
return false;
backtrace
------------[ cut here ]------------
WARNING: CPU: 7 PID: 246 at arch/x86/mm/physaddr.c:68 __virt_addr_valid+0xab/0xed
ffffc900002cb6f0 ffffffff8122168c 0000000000000000 0000000000000000
ffffc900002cb730 ffffffff810428d8 0000004400000198 ffff88041bd21022
ffffc900002cba02 1ffff920000596ed ffff88041932d1e0 ffffc900002cba00
Call Trace:
[<ffffffff8122168c>] dump_stack+0x4f/0x65
[<ffffffff810428d8>] __warn+0xc2/0xdd
[<ffffffff81042963>] warn_slowpath_null+0x1d/0x1f
[<ffffffff8103c226>] __virt_addr_valid+0xab/0xed
[<ffffffff8146d31a>] ieee80211_aes_ccm_decrypt+0x8f/0x2da
[<ffffffff812372de>] ? debug_smp_processor_id+0x17/0x19
[<ffffffff810fb7e1>] ? __put_page+0x3c/0x3f
[<ffffffff8145b879>] ? ccmp_special_blocks.isra.1+0x51/0x12d
[<ffffffff8145c445>] ieee80211_crypto_ccmp_decrypt+0x204/0x298
[<ffffffff81476dd1>] ieee80211_rx_handlers+0x7df/0x1c1d
[<ffffffff814791c1>] ieee80211_prepare_and_rx_handle+0xdc2/0xe79
[<ffffffff814793cc>] ? ieee80211_rx_napi+0x154/0x7a5
[<ffffffff814796ec>] ieee80211_rx_napi+0x474/0x7a5
[<ffffffffa01fce3b>] iwl_mvm_rx_rx_mpdu+0x6e6/0x751 [iwlmvm]
[<ffffffffa01f6c49>] iwl_mvm_rx+0x7e/0x98 [iwlmvm]
[<ffffffffa01c0bca>] iwl_pcie_rx_handle+0x523/0x698 [iwlwifi]
[<ffffffffa01c2015>] iwl_pcie_irq_handler+0x45d/0x64d [iwlwifi]
[<ffffffff81089411>] ? irq_finalize_oneshot+0xd4/0xd4
[<ffffffff8108942e>] irq_thread_fn+0x1d/0x34
[<ffffffff810896a2>] irq_thread+0xe6/0x1bb
[<ffffffff81089527>] ? wake_threads_waitq+0x2c/0x2c
[<ffffffff810895bc>] ? irq_thread_dtor+0x95/0x95
[<ffffffff8105d7a3>] kthread+0xfc/0x104
[<ffffffff8107d3ad>] ? put_lock_stats.isra.9+0xe/0x20
[<ffffffff8105d6a7>] ? kthread_create_on_node+0x3f/0x3f
[<ffffffff8105d6a7>] ? kthread_create_on_node+0x3f/0x3f
[<ffffffff8105d6a7>] ? kthread_create_on_node+0x3f/0x3f
[<ffffffff814b2952>] ret_from_fork+0x22/0x30
-ss
^ permalink raw reply
* Re: [PATCH v4 03/10] ARM: sun8i: dt: Add DT bindings documentation for Allwinner sun8i-emac
From: LABBE Corentin @ 2016-10-13 13:39 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, andrew-g2DYL2Zd6BY,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161010151335.GA3111@rob-hp-laptop>
On Mon, Oct 10, 2016 at 10:13:35AM -0500, Rob Herring wrote:
> On Fri, Oct 07, 2016 at 10:25:50AM +0200, Corentin Labbe wrote:
> > This patch adds documentation for Device-Tree bindings for the
> > Allwinner sun8i-emac driver.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > .../bindings/net/allwinner,sun8i-emac.txt | 70 ++++++++++++++++++++++
> > 1 file changed, 70 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
> > new file mode 100644
> > index 0000000..92e4ef3b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
> > @@ -0,0 +1,70 @@
> > +* Allwinner sun8i EMAC ethernet controller
> > +
> > +Required properties:
> > +- compatible: should be one of the following string:
> > + "allwinner,sun8i-a83t-emac"
> > + "allwinner,sun8i-h3-emac"
> > + "allwinner,sun50i-a64-emac"
> > +- reg: address and length of the register for the device.
> > +- syscon: A phandle to the syscon of the SoC
> > +- interrupts: interrupt for the device
> > +- clocks: A phandle to the reference clock for this device
> > +- clock-names: should be "ahb"
> > +- resets: A phandle to the reset control for this device
> > +- reset-names: should be "ahb"
> > +- phy-mode: See ethernet.txt
> > +- phy-handle: See ethernet.txt
> > +- #address-cells: shall be 1
> > +- #size-cells: shall be 0
> > +
> > +Optional properties:
> > +- allwinner,tx-delay: TX clock delay chain value. Range value is 0-0x07. Default is 0)
> > +- allwinner,rx-delay: RX clock delay chain value. Range value is 0-0x1F. Default is 0)
> > +Both delay properties does not have units, there are arbitrary value.
>
> They have to have some sort of units. Some number of clocks perhaps. Or
> just say what register field they correspond to.
>
I have re-read all 3 datasheets (A64/H3/A83T) and made string search for finding any information.
But still found nothing, no unit, no more informations than I already wrote in this file.
For the register field, just saying that it is used in the syscon register EMAC_CLK_REG is sufficient ?
> > +The TX/RX clock delay chain settings are board specific and could be found
> > +in vendor FEX files.
> > +
Regards
Corentin Labbe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 net-next 0/2] net: centralize net_device MTU bounds checking
From: David Miller @ 2016-10-13 13:37 UTC (permalink / raw)
To: jarod; +Cc: linux-kernel, netdev
In-Reply-To: <20161008020434.9691-1-jarod@redhat.com>
From: Jarod Wilson <jarod@redhat.com>
Date: Fri, 7 Oct 2016 22:04:32 -0400
> While looking into an MTU issue with sfc, I started noticing that almost
> every NIC driver with an ndo_change_mtu function implemented almost
> exactly the same range checks, and in many cases, that was the only
> practical thing their ndo_change_mtu function was doing. Quite a few
> drivers have either 68, 64, 60 or 46 as their minimum MTU value checked,
> and then various sizes from 1500 to 65535 for their maximum MTU value. We
> can remove a whole lot of redundant code here if we simple store min_mtu
> and max_mtu in net_device, and check against those in net/core/dev.c's
> dev_set_mtu().
>
> This pair of patches looks to introduce centralized MTU range checking
> infrastructure, while maintaining compatibility with all existing drivers,
> and start to make use of it, converting all eth_change_mtu/ether_setup users
> over to this new infra.
>
> Assuming these pass review muster, I've got a ton of follow-on patches to
> clean up MTU settings for everything in the kernel with an ndo_change_mtu.
>
> This work is all staged in a (rebasing) git tree here:
>
> https://github.com/jarodwilson/linux-muck
>
> The master branch is based on net-next from Oct 7, and carries these two
> patches, plus a ton of follow-on patches to eliminate MTU range checks
> and change_mtu functions where possible. All patches were successfully
> built across 160 various arch and config combos by the 0-day folks.
> (Thanks to Andrew Lunn for the suggestion to get that going).
Looks great, series applied, thanks Jarod!
^ permalink raw reply
* [PATCH net] net: bridge: add the multicast_flood flag attribute to brport_attrs
From: Nikolay Aleksandrov @ 2016-10-13 13:20 UTC (permalink / raw)
To: netdev; +Cc: stephen, roopa, davem, Nikolay Aleksandrov
When I added the multicast flood control flag, I also added an attribute
for it for sysfs similar to other flags, but I forgot to add it to
brport_attrs.
Fixes: b6cb5ac8331b ("net: bridge: add per-port multicast flood flag")
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/bridge/br_sysfs_if.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bridge/br_sysfs_if.c b/net/bridge/br_sysfs_if.c
index e657258e1f2c..8bd569695e76 100644
--- a/net/bridge/br_sysfs_if.c
+++ b/net/bridge/br_sysfs_if.c
@@ -217,6 +217,7 @@ static const struct brport_attribute *brport_attrs[] = {
#endif
&brport_attr_proxyarp,
&brport_attr_proxyarp_wifi,
+ &brport_attr_multicast_flood,
NULL
};
--
2.1.4
^ permalink raw reply related
* Re: [PATCH RFC v2 net-next 0/8] net: qualcomm: add QCA7000 UART driver
From: Greg Kroah-Hartman @ 2016-10-13 13:08 UTC (permalink / raw)
To: Stefan Wahren; +Cc: Jiri Slaby, David S. Miller, netdev, linux-kernel
In-Reply-To: <1257730210.379562.ef1d8693-0ff3-4b50-a424-49eebba23da1.open-xchange@email.1und1.de>
On Thu, Oct 13, 2016 at 10:09:09AM +0200, Stefan Wahren wrote:
>
> > Stefan Wahren <stefan.wahren@i2se.com> hat am 26. September 2016 um 13:07
> > geschrieben:
> >
> >
> > The Qualcomm QCA7000 HomePlug GreenPHY supports two interfaces:
> > UART and SPI. This patch series adds the missing support for UART.
> >
> > This driver based on the Qualcomm code [1], but contains some changes:
> > * use random MAC address per default
> > * use net_device_stats from device
> > * share frame decoding between SPI and UART driver
> > * improve error handling
> > * reimplement tty_wakeup with work queue (based on slcan)
> >
> > The patches 1 - 3 are just for clean up and are not related to
> > the UART support. Patches 4 - 7 prepare the existing QCA7000
> > code for UART support. The last patch contains the new driver.
> >
> > In order to test the driver a modified slattach in userspace is also
> > required. A prepared busybox (includes slattach) can be found here [2].
> >
> > The code itself has been tested on a Freescale i.MX28 board.
> >
> > Changes in v2:
> > * fix build issue by using netif_trans_update() and dev_trans_start()
> >
> > [1] - https://github.com/IoE/qca7000
> > [2] - https://github.com/lategoodbye/busybox/commits/qca7k_support_1_24
> >
>
> Gently ping, since i didn't receive any comment for this version.
Wait, this is an RFC, hah, I don't ever review those as obviously you
don't think well enough of it to be proposing this for inclusion :)
Fix up what you think needs to be done and resend it "for real" and it
will enter my review queue.
thanks,
greg k-h
^ permalink raw reply
* Re: [patch net-next RFC 0/6] Add support for offloading packet-sampling
From: Jamal Hadi Salim @ 2016-10-13 11:49 UTC (permalink / raw)
To: Jiri Pirko, Roopa Prabhu
Cc: netdev, davem, yotamg, idosch, eladr, nogahf, ogerlitz,
geert+renesas, stephen, xiyou.wangcong, linux
In-Reply-To: <20161013084857.GC1816@nanopsycho.orion>
On 16-10-13 04:48 AM, Jiri Pirko wrote:
> Thu, Oct 13, 2016 at 09:29:57AM CEST, roopa@cumulusnetworks.com wrote:
>> On 10/12/16, 5:41 AM, Jiri Pirko wrote:
>>> From: Jiri Pirko <jiri@mellanox.com>
>>>
[..]
>>
>> we spoke with yotam about this at netdev1.2. and also remember speaking about this on our switchdev calls:
>> Today our driver uses NFLOG to log packets to a netlink socket and hsflowd supported by the sflow
>> people (at http://www.sflow.net/) is capable of reading from a nflog socket. NFLOG has the required netlink
>> attribute markers for packet header/data (which we can possibly extend). We could also add nflog like action
>> in tc if needed.
>>
>> sflow agents like hsflowd are capable of sending packets to an external collector with the required sflow header.
>> Instead of re-inventing a new API for sflow, would be better to standardize/unify on existing mechanisms.
>>
>> Also, this patch series requires a new device to be created which can be avoided if we used
>> existing mechanisms like NFLOG.
>
> When I was first thinking about re-using NFLOG, it seemed like an
> abusal. We need to call it from driver directly, which sounds odd.
> However, since we use sample_packet_pack function to wrap it up, the
> NFLOG is called from the tc action code, it does not look bad.
> Yet still, this has nothing in common with netfilter, only using it's
> log facilities. That is odd.
>
Sorry, had not seen the code until now; helps me get perspective.
If you are going to require netfilter just so you can do this - it
sounds so wrong (since you already provides a hook for tc offloading
into the switch for other functions).
Roopa, did you mean eth1 as the new device or did you mean just in
general config requiring a device to be specified or did you mean a new
cpu netdev being needed? I couldnt tell from the patch.
> I think that the IFE ways is way more clear and generic and not-abusing.
> However you are right the NFLOG way has advantage of existing user
> component. I'm not sure how to do this :(
Can you do NFLOG to user space without requiring netfilter compiled in?
One advantage with IFE is it is a wire protocol - so you can have the
sflow collector/aggregator sit on a different machine (for small cpu
switches makes sense). So modifying the sflow daemon to accept IFE
formatted data is an interesting!
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Paul Bolle @ 2016-10-13 12:55 UTC (permalink / raw)
To: Luca Coelho, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
chris-FAYdYWbMHyxBDgjK7y7TUQ
Cc: linuxwifi-ral2JQCrhuEAvxtiuMwx3w,
emmanuel.grumbach-ral2JQCrhuEAvxtiuMwx3w,
johannes-cdvu00un1VgdHxzADdlk8Q, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
oren.givon-ral2JQCrhuEAvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476362653.3880.25.camel-XPOmlcxoEMv1KXRcyAk9cg@public.gmane.org>
On Thu, 2016-10-13 at 15:44 +0300, Luca Coelho wrote:
> Even though there is apparently something wrong with this part of the
> ACPI table on you laptop, since it doesn't match our specifications.
> In any case, it's mostly harmless.
Would a correct implementation by Dell have any benefits for the users
of these laptops? In other words: should I bother somehow contacting
Dell and point them to this discussion in order to have them fix this?
Paul Bolle
^ permalink raw reply
* Re: [patch net-next RFC 0/6] Add support for offloading packet-sampling
From: Jamal Hadi Salim @ 2016-10-13 12:30 UTC (permalink / raw)
To: Jiri Pirko
Cc: Roopa Prabhu, netdev, davem, yotamg, idosch, eladr, nogahf,
ogerlitz, geert+renesas, stephen, xiyou.wangcong, linux
In-Reply-To: <20161013121022.GD1816@nanopsycho.orion>
On 16-10-13 08:10 AM, Jiri Pirko wrote:
> Thu, Oct 13, 2016 at 01:49:07PM CEST, jhs@mojatatu.com wrote:
>> On 16-10-13 04:48 AM, Jiri Pirko wrote:
[..]
>> Roopa, did you mean eth1 as the new device or did you mean just in
>> general config requiring a device to be specified or did you mean a new
>> cpu netdev being needed? I couldnt tell from the patch.
>
> You just have to have some netdev to use to funnel the IFE headered
> sample skbs to userspace. A dummy or a tap.
>
I see.
So with nflog you get basically a backend using a netlink socket
but in your case you will redirect to tuntap for the case of local
sflow but some other device for remote? I am assuming using dummy
would require a packet socket as means of retrieving the data.
If you take the structuring of the metadata that nflog uses it should
be easy to transpose.
To Roopa's point, however: Would it not make sense to support nflog
(in addition?).
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next RFC 0/6] Add support for offloading packet-sampling
From: Jiri Pirko @ 2016-10-13 12:45 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Roopa Prabhu, netdev, davem, yotamg, idosch, eladr, nogahf,
ogerlitz, geert+renesas, stephen, xiyou.wangcong, linux
In-Reply-To: <2cc65dfa-de32-2e31-5f03-80e8f0d2586f@mojatatu.com>
Thu, Oct 13, 2016 at 02:30:19PM CEST, jhs@mojatatu.com wrote:
>On 16-10-13 08:10 AM, Jiri Pirko wrote:
>> Thu, Oct 13, 2016 at 01:49:07PM CEST, jhs@mojatatu.com wrote:
>> > On 16-10-13 04:48 AM, Jiri Pirko wrote:
>
>[..]
>> > Roopa, did you mean eth1 as the new device or did you mean just in
>> > general config requiring a device to be specified or did you mean a new
>> > cpu netdev being needed? I couldnt tell from the patch.
>>
>> You just have to have some netdev to use to funnel the IFE headered
>> sample skbs to userspace. A dummy or a tap.
>>
>
>I see.
>So with nflog you get basically a backend using a netlink socket
>but in your case you will redirect to tuntap for the case of local
>sflow but some other device for remote? I am assuming using dummy
>would require a packet socket as means of retrieving the data.
Correct. The idea is that the userspace app would create a tap device,
setup the sampling packets to be sent there and recieve them
over chardev. Or the remote delivery could be use to push the sampling
packet to a remote host.
>If you take the structuring of the metadata that nflog uses it should
>be easy to transpose.
Yes, we do it with IFE, this patchset implements that.
>To Roopa's point, however: Would it not make sense to support nflog
>(in addition?).
>
>cheers,
>jamal
>
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Luca Coelho @ 2016-10-13 12:44 UTC (permalink / raw)
To: Paul Bolle, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
chris-FAYdYWbMHyxBDgjK7y7TUQ
Cc: linuxwifi-ral2JQCrhuEAvxtiuMwx3w,
emmanuel.grumbach-ral2JQCrhuEAvxtiuMwx3w,
johannes-cdvu00un1VgdHxzADdlk8Q, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
oren.givon-ral2JQCrhuEAvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476362194.1999.11.camel-IWqWACnzNjzz+pZb47iToQ@public.gmane.org>
On Thu, 2016-10-13 at 14:36 +0200, Paul Bolle wrote:
> On Thu, 2016-10-13 at 14:30 +0300, Luca Coelho wrote:
> > I forgot to say... could you load the iwlwifi module with debug=0x01
> > (module parameter), so we can see the messages the driver is printing
> > when it doesn't find a proper structure?
>
>
> That makes a lot of noise! Here's the first 100 lines or so, that
> apparently are generated directly after modprobing iwlwifi.
>
> After these 100 lines there's a ten second gap (I guess it took me ten
> seconds to actually use the wifi). I assume you don't care about that
> part of the debug messages.
>
> Have fun!
Thanks, Paul!
Yeah, this is the "INFO" debugging level and it is a sort of fallback
bucket when there is nothing more specific. Sorry for that.
> <7>[ 767.691342] iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
> <7>[ 767.691362] iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
> <7>[ 767.692127] iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load firmware 'iwlwifi-8000C-24.ucode'
> <7>[ 767.692322] iwlwifi 0000:3a:00.0: U splc_get_pwr_limit No element for the WiFi domain returned by the SPLC method.
This is the line I was looking for. :) So everything looks fine now.
Even though there is apparently something wrong with this part of the
ACPI table on you laptop, since it doesn't match our specifications.
In any case, it's mostly harmless.
Thanks for the help!
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Paul Bolle @ 2016-10-13 12:36 UTC (permalink / raw)
To: Luca Coelho, linux-wireless, chris
Cc: linuxwifi, emmanuel.grumbach, johannes, kvalo, oren.givon, netdev,
linux-kernel
In-Reply-To: <1476358222.3880.21.camel@coelho.fi>
On Thu, 2016-10-13 at 14:30 +0300, Luca Coelho wrote:
> I forgot to say... could you load the iwlwifi module with debug=0x01
> (module parameter), so we can see the messages the driver is printing
> when it doesn't find a proper structure?
That makes a lot of noise! Here's the first 100 lines or so, that
apparently are generated directly after modprobing iwlwifi.
After these 100 lines there's a ten second gap (I guess it took me ten
seconds to actually use the wifi). I assume you don't care about that
part of the debug messages.
Have fun!
Paul Bolle
<7>[ 767.691342] iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
<7>[ 767.691362] iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
<7>[ 767.692127] iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load firmware 'iwlwifi-8000C-24.ucode'
<7>[ 767.692322] iwlwifi 0000:3a:00.0: U splc_get_pwr_limit No element for the WiFi domain returned by the SPLC method.
<7>[ 767.692324] iwlwifi 0000:3a:00.0: U set_dflt_pwr_limit Default power limit set to 0
<4>[ 767.692672] iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-24.ucode failed with error -2
<7>[ 767.692674] iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load firmware 'iwlwifi-8000C-23.ucode'
<4>[ 767.692683] iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-23.ucode failed with error -2
<7>[ 767.692684] iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load firmware 'iwlwifi-8000C-22.ucode'
<7>[ 767.693267] iwlwifi 0000:3a:00.0: U iwl_req_fw_callback Loaded firmware file 'iwlwifi-8000C-22.ucode' (2120860 bytes).
<7>[ 767.693271] iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware Found debug memory segment: 0
<7>[ 767.693272] iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware Found debug memory segment: 1
<7>[ 767.693274] iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware Found debug memory segment: 2
<7>[ 767.693276] iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware unknown TLV: 48
<7>[ 767.693278] iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware GSCAN is supported but capabilities TLV is unavailable
<6>[ 767.693829] iwlwifi 0000:3a:00.0: loaded firmware version 22.361476.0 op_mode iwlmvm
<6>[ 767.747133] iwlwifi 0000:3a:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
<7>[ 767.747141] iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
<7>[ 767.747168] iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
<7>[ 767.749221] iwlwifi 0000:3a:00.0: U iwl_pcie_apm_init Init card's basic functions
<6>[ 767.749257] iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
<7>[ 767.749855] iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
<7>[ 767.749870] iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
<7>[ 767.749878] iwlwifi 0000:3a:00.0: U iwl_pcie_apm_init Init card's basic functions
<6>[ 767.749896] iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
<7>[ 767.749906] iwlwifi 0000:3a:00.0: U iwl_mvm_nic_config Radio type=0x0-0x2-0x1
<7>[ 767.750608] iwlwifi 0000:3a:00.0: U iwl_pcie_nic_init Enabling shadow registers in device
<7>[ 767.750624] iwlwifi 0000:3a:00.0: U iwl_pcie_rsa_race_bug_wa can't access the RSA semaphore it is write protected
<7>[ 767.810446] iwlwifi 0000:3a:00.0: I iwl_mvm_rx_mfuart_notif MFUART: installed ver: 0x12000415, external ver: 0x12000415, status: 0x00010080, duration: 0x00000006
<7>[ 767.810861] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command BT_CONFIG
<7>[ 767.810862] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command BT_CONFIG
<7>[ 767.810984] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command BT_CONFIG
<7>[ 767.811023] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811025] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811098] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811102] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811103] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811212] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811222] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811223] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811318] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811326] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811327] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811451] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811459] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811460] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811555] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811564] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811565] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811672] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811681] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811682] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811742] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811746] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811747] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811837] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811842] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811843] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811944] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811952] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811953] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812011] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812016] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.812017] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812073] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812077] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.812077] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812142] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812146] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.812147] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812201] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812204] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.812205] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812276] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812281] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.812281] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812344] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812366] iwlwifi 0000:3a:00.0: U iwl_nvm_check_version device EEPROM VER=0xe56, CALIB=0xff
<7>[ 767.812368] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command TX_ANT_CONFIGURATION_CMD
<7>[ 767.812369] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command TX_ANT_CONFIGURATION_CMD
<7>[ 767.812422] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command TX_ANT_CONFIGURATION_CMD
<7>[ 767.812425] iwlwifi 0000:3a:00.0: U iwl_send_phy_cfg_cmd Sending Phy CFG command: 0x330018
<7>[ 767.812426] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command PHY_CONFIGURATION_CMD
<7>[ 767.812427] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command PHY_CONFIGURATION_CMD
<7>[ 767.812480] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command PHY_CONFIGURATION_CMD
<7>[ 767.871057] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 1 , Size: 3684
<7>[ 767.871065] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 2 , Size: 4
<7>[ 767.871071] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871108] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871263] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871441] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871607] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871782] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871814] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871955] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872084] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872216] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872346] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872478] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872622] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872764] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872871] iwlwifi 0000:3a:00.0: U _iwl_trans_pcie_stop_device DEVICE_ENABLED bit was set and is now cleared
<7>[ 767.872961] iwlwifi 0000:3a:00.0: U iwl_pcie_apm_stop Stop card, put in low power state
<7>[ 767.872980] iwlwifi 0000:3a:00.0: U iwl_pcie_apm_stop_master stop master
<7>[ 767.877089] iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
<7>[ 767.877119] iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
<6>[ 767.905185] iwlwifi 0000:3a:00.0 wlp58s0: renamed from wlan0
^ permalink raw reply
* Re: [patch net-next RFC 0/6] Add support for offloading packet-sampling
From: Jiri Pirko @ 2016-10-13 12:10 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Roopa Prabhu, netdev, davem, yotamg, idosch, eladr, nogahf,
ogerlitz, geert+renesas, stephen, xiyou.wangcong, linux
In-Reply-To: <64872c5b-8cbc-edd8-00aa-afc87a7cfa4a@mojatatu.com>
Thu, Oct 13, 2016 at 01:49:07PM CEST, jhs@mojatatu.com wrote:
>On 16-10-13 04:48 AM, Jiri Pirko wrote:
>> Thu, Oct 13, 2016 at 09:29:57AM CEST, roopa@cumulusnetworks.com wrote:
>> > On 10/12/16, 5:41 AM, Jiri Pirko wrote:
>> > > From: Jiri Pirko <jiri@mellanox.com>
>> > >
>[..]
>> >
>> > we spoke with yotam about this at netdev1.2. and also remember speaking about this on our switchdev calls:
>> > Today our driver uses NFLOG to log packets to a netlink socket and hsflowd supported by the sflow
>> > people (at http://www.sflow.net/) is capable of reading from a nflog socket. NFLOG has the required netlink
>> > attribute markers for packet header/data (which we can possibly extend). We could also add nflog like action
>> > in tc if needed.
>> >
>> > sflow agents like hsflowd are capable of sending packets to an external collector with the required sflow header.
>> > Instead of re-inventing a new API for sflow, would be better to standardize/unify on existing mechanisms.
>> >
>> > Also, this patch series requires a new device to be created which can be avoided if we used
>> > existing mechanisms like NFLOG.
>>
>> When I was first thinking about re-using NFLOG, it seemed like an
>> abusal. We need to call it from driver directly, which sounds odd.
>> However, since we use sample_packet_pack function to wrap it up, the
>> NFLOG is called from the tc action code, it does not look bad.
>> Yet still, this has nothing in common with netfilter, only using it's
>> log facilities. That is odd.
>>
>
>Sorry, had not seen the code until now; helps me get perspective.
>If you are going to require netfilter just so you can do this - it
>sounds so wrong (since you already provides a hook for tc offloading
>into the switch for other functions).
+1
>Roopa, did you mean eth1 as the new device or did you mean just in
>general config requiring a device to be specified or did you mean a new
>cpu netdev being needed? I couldnt tell from the patch.
You just have to have some netdev to use to funnel the IFE headered
sample skbs to userspace. A dummy or a tap.
>
>> I think that the IFE ways is way more clear and generic and not-abusing.
>> However you are right the NFLOG way has advantage of existing user
>> component. I'm not sure how to do this :(
>
>Can you do NFLOG to user space without requiring netfilter compiled in?
>One advantage with IFE is it is a wire protocol - so you can have the
>sflow collector/aggregator sit on a different machine (for small cpu
>switches makes sense). So modifying the sflow daemon to accept IFE
>formatted data is an interesting!
Agreed. For me, that looks like the correct way to do this.
>
>cheers,
>jamal
^ permalink raw reply
* Re: [PATCH v4 net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: Jamal Hadi Salim @ 2016-10-13 11:58 UTC (permalink / raw)
To: Shmulik Ladkani, David Miller
Cc: Eric Dumazet, WANG Cong, Daniel Borkmann, netdev, Eric Dumazet
In-Reply-To: <1476338804-25440-5-git-send-email-shmulik.ladkani@gmail.com>
On 16-10-13 02:06 AM, Shmulik Ladkani wrote:
> Up until now, 'action mirred' supported only egress actions (either
> TCA_EGRESS_REDIR or TCA_EGRESS_MIRROR).
>
> This patch implements the corresponding ingress actions
> TCA_INGRESS_REDIR and TCA_INGRESS_MIRROR.
>
> This allows attaching filters whose target is to hand matching skbs into
> the rx processing of a specified device.
>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Tested-by: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v4 net-next 3/4] net/sched: tc_mirred: Rename public predicates 'is_tcf_mirred_redirect' and 'is_tcf_mirred_mirror'
From: Jamal Hadi Salim @ 2016-10-13 11:57 UTC (permalink / raw)
To: Shmulik Ladkani, David Miller
Cc: Eric Dumazet, WANG Cong, Daniel Borkmann, netdev, Hariprasad S,
Jeff Kirsher, Saeed Mahameed, Jiri Pirko, Ido Schimmel,
Jakub Kicinski
In-Reply-To: <1476338804-25440-4-git-send-email-shmulik.ladkani@gmail.com>
On 16-10-13 02:06 AM, Shmulik Ladkani wrote:
> These accessors are used in various drivers that support tc offloading,
> to detect properties of a given 'tc_action'.
>
> 'is_tcf_mirred_redirect' tests that the action is TCA_EGRESS_REDIR.
> 'is_tcf_mirred_mirror' tests that the action is TCA_EGRESS_MIRROR.
>
> As a prep towards supporting INGRESS redir/mirror, rename these
> predicates to reflect their true meaning:
> s/is_tcf_mirred_redirect/is_tcf_mirred_egress_redirect/
> s/is_tcf_mirred_mirror/is_tcf_mirred_egress_mirror/
>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* [PATCH v2 net-next 7/7] qed: Fix possible race when reading firmware return code.
From: Manish Chopra @ 2016-10-13 11:22 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz, Manish Chopra
In-Reply-To: <1476357771-1578-1-git-send-email-manish.chopra@qlogic.com>
From: Manish Chopra <manish.chopra@caviumnetworks.com>
While handling SPQ ramrod completion, there is a possible race
where driver might not read updated fw return code based on
ramrod completion done. This patch ensures that fw return code
is written first and then completion done flag is updated
using appropriate memory barriers.
Signed-off-by: Manish Chopra <manish.chopra@caviumnetworks.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
---
drivers/net/ethernet/qlogic/qed/qed_spq.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_spq.c b/drivers/net/ethernet/qlogic/qed/qed_spq.c
index 259a615..6c05402 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_spq.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_spq.c
@@ -54,11 +54,10 @@ static void qed_spq_blocking_cb(struct qed_hwfn *p_hwfn,
comp_done = (struct qed_spq_comp_done *)cookie;
- comp_done->done = 0x1;
- comp_done->fw_return_code = fw_return_code;
+ comp_done->fw_return_code = fw_return_code;
- /* make update visible to waiting thread */
- smp_wmb();
+ /* Make sure completion done is visible on waiting thread */
+ smp_store_release(&comp_done->done, 0x1);
}
static int __qed_spq_block(struct qed_hwfn *p_hwfn,
@@ -74,8 +73,9 @@ static int __qed_spq_block(struct qed_hwfn *p_hwfn,
while (iter_cnt--) {
/* Validate we receive completion update */
- smp_rmb();
- if (comp_done->done == 1) {
+ if (READ_ONCE(comp_done->done) == 1) {
+ /* Read updated FW return value */
+ smp_read_barrier_depends();
if (p_fw_ret)
*p_fw_ret = comp_done->fw_return_code;
return 0;
--
2.7.2
^ permalink raw reply related
* [PATCH v2 net-next 0/7] qed*: driver updates
From: Manish Chopra @ 2016-10-13 11:22 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz, Manish Chopra
From: Manish Chopra <manish.chopra@caviumnetworks.com>
Hi David,
There are several new additions in this series;
Most are connected to either Tx offloading or Rx classifications
[either fastpath changes or supporting configuration].
In addition, there's a single IOV enhancement.
Please consider applying this series to `net-next'.
V2:
Added a fix for the race in ramrod handling
pointed by Eric Dumazet [patch 7].
Thanks,
Manish
Manish Chopra (3):
qede: GSO support for tunnels with outer csum
qede: Prevent GSO on long Geneve headers
qed: Fix possible race when reading firmware return code.
Yuval Mintz (4):
qed: Pass MAC hints to VFs
qed*: Allow unicast filtering
qed: Allow chance for fast ramrod completions
qed: Handle malicious VFs events
drivers/net/ethernet/qlogic/qed/qed_l2.c | 12 ++-
drivers/net/ethernet/qlogic/qed/qed_spq.c | 97 +++++++++++++++--------
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 114 ++++++++++++++++++++++-----
drivers/net/ethernet/qlogic/qed/qed_sriov.h | 1 +
drivers/net/ethernet/qlogic/qed/qed_vf.c | 4 +-
drivers/net/ethernet/qlogic/qed/qed_vf.h | 1 +
drivers/net/ethernet/qlogic/qede/qede.h | 1 +
drivers/net/ethernet/qlogic/qede/qede_main.c | 71 +++++++++++++++--
include/linux/qed/qed_eth_if.h | 3 +-
9 files changed, 242 insertions(+), 62 deletions(-)
--
2.7.2
^ permalink raw reply
* [PATCH v2 net-next 6/7] qed: Handle malicious VFs events
From: Manish Chopra @ 2016-10-13 11:22 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz, Yuval Mintz
In-Reply-To: <1476357771-1578-1-git-send-email-manish.chopra@qlogic.com>
From: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
Malicious VFs might be caught in several different methods:
- Misusing their bar permission and being blocked by hardware.
- Misusing their fastpath logic and being blocked by firmware.
- Misusing their interaction with their PF via hw-channel,
and being blocked by PF driver.
On the first two items, firmware would indicate to driver that
the VF is to be considered malicious, but would sometime still
allow the VF to communicate with the PF [depending on the exact
nature of the malicious activity done by the VF].
The current existing logic on the PF side lacks handling of such events,
and might allow the PF to perform some incorrect configuration on behalf
of a VF that was previously indicated as malicious.
The new scheme is simple -
Once the PF determines a VF is malicious it would:
a. Ignore any further requests on behalf of the VF-driver.
b. Prevent any configurations initiated by the hyperuser for
the malicious VF, as firmware isn't willing to serve such.
The malicious indication would be cleared upon the VF flr,
after which it would become usable once again.
Signed-off-by: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
---
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 114 +++++++++++++++++++++++-----
drivers/net/ethernet/qlogic/qed/qed_sriov.h | 1 +
drivers/net/ethernet/qlogic/qed/qed_vf.h | 1 +
3 files changed, 96 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index d2d6621..6f029f9 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -109,7 +109,8 @@ static int qed_sp_vf_stop(struct qed_hwfn *p_hwfn,
}
static bool qed_iov_is_valid_vfid(struct qed_hwfn *p_hwfn,
- int rel_vf_id, bool b_enabled_only)
+ int rel_vf_id,
+ bool b_enabled_only, bool b_non_malicious)
{
if (!p_hwfn->pf_iov_info) {
DP_NOTICE(p_hwfn->cdev, "No iov info\n");
@@ -124,6 +125,10 @@ static bool qed_iov_is_valid_vfid(struct qed_hwfn *p_hwfn,
b_enabled_only)
return false;
+ if ((p_hwfn->pf_iov_info->vfs_array[rel_vf_id].b_malicious) &&
+ b_non_malicious)
+ return false;
+
return true;
}
@@ -138,7 +143,8 @@ static struct qed_vf_info *qed_iov_get_vf_info(struct qed_hwfn *p_hwfn,
return NULL;
}
- if (qed_iov_is_valid_vfid(p_hwfn, relative_vf_id, b_enabled_only))
+ if (qed_iov_is_valid_vfid(p_hwfn, relative_vf_id,
+ b_enabled_only, false))
vf = &p_hwfn->pf_iov_info->vfs_array[relative_vf_id];
else
DP_ERR(p_hwfn, "qed_iov_get_vf_info: VF[%d] is not enabled\n",
@@ -542,7 +548,8 @@ int qed_iov_hw_info(struct qed_hwfn *p_hwfn)
return 0;
}
-static bool qed_iov_pf_sanity_check(struct qed_hwfn *p_hwfn, int vfid)
+bool _qed_iov_pf_sanity_check(struct qed_hwfn *p_hwfn,
+ int vfid, bool b_fail_malicious)
{
/* Check PF supports sriov */
if (IS_VF(p_hwfn->cdev) || !IS_QED_SRIOV(p_hwfn->cdev) ||
@@ -550,12 +557,17 @@ static bool qed_iov_pf_sanity_check(struct qed_hwfn *p_hwfn, int vfid)
return false;
/* Check VF validity */
- if (!qed_iov_is_valid_vfid(p_hwfn, vfid, true))
+ if (!qed_iov_is_valid_vfid(p_hwfn, vfid, true, b_fail_malicious))
return false;
return true;
}
+bool qed_iov_pf_sanity_check(struct qed_hwfn *p_hwfn, int vfid)
+{
+ return _qed_iov_pf_sanity_check(p_hwfn, vfid, true);
+}
+
static void qed_iov_set_vf_to_disable(struct qed_dev *cdev,
u16 rel_vf_id, u8 to_disable)
{
@@ -652,6 +664,9 @@ static int qed_iov_enable_vf_access(struct qed_hwfn *p_hwfn,
qed_iov_vf_igu_reset(p_hwfn, p_ptt, vf);
+ /* It's possible VF was previously considered malicious */
+ vf->b_malicious = false;
+
rc = qed_mcp_config_vf_msix(p_hwfn, p_ptt, vf->abs_vf_id, vf->num_sbs);
if (rc)
return rc;
@@ -2804,6 +2819,13 @@ qed_iov_execute_vf_flr_cleanup(struct qed_hwfn *p_hwfn,
return rc;
}
+ /* Workaround to make VF-PF channel ready, as FW
+ * doesn't do that as a part of FLR.
+ */
+ REG_WR(p_hwfn,
+ GTT_BAR0_MAP_REG_USDM_RAM +
+ USTORM_VF_PF_CHANNEL_READY_OFFSET(vfid), 1);
+
/* VF_STOPPED has to be set only after final cleanup
* but prior to re-enabling the VF.
*/
@@ -2942,7 +2964,8 @@ static void qed_iov_process_mbx_req(struct qed_hwfn *p_hwfn,
mbx->first_tlv = mbx->req_virt->first_tlv;
/* check if tlv type is known */
- if (qed_iov_tlv_supported(mbx->first_tlv.tl.type)) {
+ if (qed_iov_tlv_supported(mbx->first_tlv.tl.type) &&
+ !p_vf->b_malicious) {
switch (mbx->first_tlv.tl.type) {
case CHANNEL_TLV_ACQUIRE:
qed_iov_vf_mbx_acquire(p_hwfn, p_ptt, p_vf);
@@ -2984,6 +3007,15 @@ static void qed_iov_process_mbx_req(struct qed_hwfn *p_hwfn,
qed_iov_vf_mbx_release(p_hwfn, p_ptt, p_vf);
break;
}
+ } else if (qed_iov_tlv_supported(mbx->first_tlv.tl.type)) {
+ DP_VERBOSE(p_hwfn, QED_MSG_IOV,
+ "VF [%02x] - considered malicious; Ignoring TLV [%04x]\n",
+ p_vf->abs_vf_id, mbx->first_tlv.tl.type);
+
+ qed_iov_prepare_resp(p_hwfn, p_ptt, p_vf,
+ mbx->first_tlv.tl.type,
+ sizeof(struct pfvf_def_resp_tlv),
+ PFVF_STATUS_MALICIOUS);
} else {
/* unknown TLV - this may belong to a VF driver from the future
* - a version written after this PF driver was written, which
@@ -3033,20 +3065,30 @@ static void qed_iov_pf_get_and_clear_pending_events(struct qed_hwfn *p_hwfn,
memset(p_pending_events, 0, sizeof(u64) * QED_VF_ARRAY_LENGTH);
}
-static int qed_sriov_vfpf_msg(struct qed_hwfn *p_hwfn,
- u16 abs_vfid, struct regpair *vf_msg)
+static struct qed_vf_info *qed_sriov_get_vf_from_absid(struct qed_hwfn *p_hwfn,
+ u16 abs_vfid)
{
- u8 min = (u8)p_hwfn->cdev->p_iov_info->first_vf_in_pf;
- struct qed_vf_info *p_vf;
+ u8 min = (u8) p_hwfn->cdev->p_iov_info->first_vf_in_pf;
- if (!qed_iov_pf_sanity_check(p_hwfn, (int)abs_vfid - min)) {
+ if (!_qed_iov_pf_sanity_check(p_hwfn, (int)abs_vfid - min, false)) {
DP_VERBOSE(p_hwfn,
QED_MSG_IOV,
- "Got a message from VF [abs 0x%08x] that cannot be handled by PF\n",
+ "Got indication for VF [abs 0x%08x] that cannot be handled by PF\n",
abs_vfid);
- return 0;
+ return NULL;
}
- p_vf = &p_hwfn->pf_iov_info->vfs_array[(u8)abs_vfid - min];
+
+ return &p_hwfn->pf_iov_info->vfs_array[(u8) abs_vfid - min];
+}
+
+static int qed_sriov_vfpf_msg(struct qed_hwfn *p_hwfn,
+ u16 abs_vfid, struct regpair *vf_msg)
+{
+ struct qed_vf_info *p_vf = qed_sriov_get_vf_from_absid(p_hwfn,
+ abs_vfid);
+
+ if (!p_vf)
+ return 0;
/* List the physical address of the request so that handler
* could later on copy the message from it.
@@ -3060,6 +3102,23 @@ static int qed_sriov_vfpf_msg(struct qed_hwfn *p_hwfn,
return 0;
}
+static void qed_sriov_vfpf_malicious(struct qed_hwfn *p_hwfn,
+ struct malicious_vf_eqe_data *p_data)
+{
+ struct qed_vf_info *p_vf;
+
+ p_vf = qed_sriov_get_vf_from_absid(p_hwfn, p_data->vf_id);
+
+ if (!p_vf)
+ return;
+
+ DP_INFO(p_hwfn,
+ "VF [%d] - Malicious behavior [%02x]\n",
+ p_vf->abs_vf_id, p_data->err_id);
+
+ p_vf->b_malicious = true;
+}
+
int qed_sriov_eqe_event(struct qed_hwfn *p_hwfn,
u8 opcode, __le16 echo, union event_ring_data *data)
{
@@ -3067,6 +3126,9 @@ int qed_sriov_eqe_event(struct qed_hwfn *p_hwfn,
case COMMON_EVENT_VF_PF_CHANNEL:
return qed_sriov_vfpf_msg(p_hwfn, le16_to_cpu(echo),
&data->vf_pf_channel.msg_addr);
+ case COMMON_EVENT_MALICIOUS_VF:
+ qed_sriov_vfpf_malicious(p_hwfn, &data->malicious_vf);
+ return 0;
default:
DP_INFO(p_hwfn->cdev, "Unknown sriov eqe event 0x%02x\n",
opcode);
@@ -3083,7 +3145,7 @@ u16 qed_iov_get_next_active_vf(struct qed_hwfn *p_hwfn, u16 rel_vf_id)
goto out;
for (i = rel_vf_id; i < p_iov->total_vfs; i++)
- if (qed_iov_is_valid_vfid(p_hwfn, rel_vf_id, true))
+ if (qed_iov_is_valid_vfid(p_hwfn, rel_vf_id, true, false))
return i;
out:
@@ -3130,6 +3192,12 @@ static void qed_iov_bulletin_set_forced_mac(struct qed_hwfn *p_hwfn,
return;
}
+ if (vf_info->b_malicious) {
+ DP_NOTICE(p_hwfn->cdev,
+ "Can't set forced MAC to malicious VF [%d]\n", vfid);
+ return;
+ }
+
feature = 1 << MAC_ADDR_FORCED;
memcpy(vf_info->bulletin.p_virt->mac, mac, ETH_ALEN);
@@ -3153,6 +3221,12 @@ static void qed_iov_bulletin_set_forced_vlan(struct qed_hwfn *p_hwfn,
return;
}
+ if (vf_info->b_malicious) {
+ DP_NOTICE(p_hwfn->cdev,
+ "Can't set forced vlan to malicious VF [%d]\n", vfid);
+ return;
+ }
+
feature = 1 << VLAN_ADDR_FORCED;
vf_info->bulletin.p_virt->pvid = pvid;
if (pvid)
@@ -3367,7 +3441,7 @@ int qed_sriov_disable(struct qed_dev *cdev, bool pci_enabled)
qed_for_each_vf(hwfn, j) {
int k;
- if (!qed_iov_is_valid_vfid(hwfn, j, true))
+ if (!qed_iov_is_valid_vfid(hwfn, j, true, false))
continue;
/* Wait until VF is disabled before releasing */
@@ -3425,7 +3499,7 @@ static int qed_sriov_enable(struct qed_dev *cdev, int num)
num_sbs = min_t(int, sb_cnt_info.sb_free_blk, limit);
for (i = 0; i < num; i++) {
- if (!qed_iov_is_valid_vfid(hwfn, i, false))
+ if (!qed_iov_is_valid_vfid(hwfn, i, false, true))
continue;
rc = qed_iov_init_hw_for_vf(hwfn,
@@ -3477,7 +3551,7 @@ static int qed_sriov_pf_set_mac(struct qed_dev *cdev, u8 *mac, int vfid)
return -EINVAL;
}
- if (!qed_iov_is_valid_vfid(&cdev->hwfns[0], vfid, true)) {
+ if (!qed_iov_is_valid_vfid(&cdev->hwfns[0], vfid, true, true)) {
DP_VERBOSE(cdev, QED_MSG_IOV,
"Cannot set VF[%d] MAC (VF is not active)\n", vfid);
return -EINVAL;
@@ -3509,7 +3583,7 @@ static int qed_sriov_pf_set_vlan(struct qed_dev *cdev, u16 vid, int vfid)
return -EINVAL;
}
- if (!qed_iov_is_valid_vfid(&cdev->hwfns[0], vfid, true)) {
+ if (!qed_iov_is_valid_vfid(&cdev->hwfns[0], vfid, true, true)) {
DP_VERBOSE(cdev, QED_MSG_IOV,
"Cannot set VF[%d] MAC (VF is not active)\n", vfid);
return -EINVAL;
@@ -3543,7 +3617,7 @@ static int qed_get_vf_config(struct qed_dev *cdev,
if (IS_VF(cdev))
return -EINVAL;
- if (!qed_iov_is_valid_vfid(&cdev->hwfns[0], vf_id, true)) {
+ if (!qed_iov_is_valid_vfid(&cdev->hwfns[0], vf_id, true, false)) {
DP_VERBOSE(cdev, QED_MSG_IOV,
"VF index [%d] isn't active\n", vf_id);
return -EINVAL;
@@ -3647,7 +3721,7 @@ static int qed_set_vf_link_state(struct qed_dev *cdev,
if (IS_VF(cdev))
return -EINVAL;
- if (!qed_iov_is_valid_vfid(&cdev->hwfns[0], vf_id, true)) {
+ if (!qed_iov_is_valid_vfid(&cdev->hwfns[0], vf_id, true, true)) {
DP_VERBOSE(cdev, QED_MSG_IOV,
"VF index [%d] isn't active\n", vf_id);
return -EINVAL;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.h b/drivers/net/ethernet/qlogic/qed/qed_sriov.h
index 0dd23e4..3cf515b 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.h
@@ -132,6 +132,7 @@ struct qed_vf_info {
struct qed_iov_vf_mbx vf_mbx;
enum vf_state state;
bool b_init;
+ bool b_malicious;
u8 to_disable;
struct qed_bulletin bulletin;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.h b/drivers/net/ethernet/qlogic/qed/qed_vf.h
index 35db7a28..944745b 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.h
@@ -40,6 +40,7 @@ enum {
PFVF_STATUS_NOT_SUPPORTED,
PFVF_STATUS_NO_RESOURCE,
PFVF_STATUS_FORCED,
+ PFVF_STATUS_MALICIOUS,
};
/* vf pf channel tlvs */
--
2.7.2
^ permalink raw reply related
* [PATCH v2 net-next 3/7] qede: Prevent GSO on long Geneve headers
From: Manish Chopra @ 2016-10-13 11:22 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz, Manish Chopra
In-Reply-To: <1476357771-1578-1-git-send-email-manish.chopra@qlogic.com>
From: Manish Chopra <manish.chopra@caviumnetworks.com>
Due to hardware limitation, when transmitting a geneve-encapsulated
packet with more than 32 bytes worth of geneve options the hardware
would not be able to crack the packet and consider it a regular UDP
packet.
This implements the ndo_features_check() in qede in order to prevent
GSO on said transmitted packets.
Signed-off-by: Manish Chopra <manish.chopra@caviumnetworks.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
---
drivers/net/ethernet/qlogic/qede/qede_main.c | 35 ++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 7d5dc1e..6c2b09c 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -2240,6 +2240,40 @@ static void qede_udp_tunnel_del(struct net_device *dev,
schedule_delayed_work(&edev->sp_task, 0);
}
+/* 8B udp header + 8B base tunnel header + 32B option length */
+#define QEDE_MAX_TUN_HDR_LEN 48
+
+static netdev_features_t qede_features_check(struct sk_buff *skb,
+ struct net_device *dev,
+ netdev_features_t features)
+{
+ if (skb->encapsulation) {
+ u8 l4_proto = 0;
+
+ switch (vlan_get_protocol(skb)) {
+ case htons(ETH_P_IP):
+ l4_proto = ip_hdr(skb)->protocol;
+ break;
+ case htons(ETH_P_IPV6):
+ l4_proto = ipv6_hdr(skb)->nexthdr;
+ break;
+ default:
+ return features;
+ }
+
+ /* Disable offloads for geneve tunnels, as HW can't parse
+ * the geneve header which has option length greater than 32B.
+ */
+ if ((l4_proto == IPPROTO_UDP) &&
+ ((skb_inner_mac_header(skb) -
+ skb_transport_header(skb)) > QEDE_MAX_TUN_HDR_LEN))
+ return features & ~(NETIF_F_CSUM_MASK |
+ NETIF_F_GSO_MASK);
+ }
+
+ return features;
+}
+
static const struct net_device_ops qede_netdev_ops = {
.ndo_open = qede_open,
.ndo_stop = qede_close,
@@ -2264,6 +2298,7 @@ static const struct net_device_ops qede_netdev_ops = {
#endif
.ndo_udp_tunnel_add = qede_udp_tunnel_add,
.ndo_udp_tunnel_del = qede_udp_tunnel_del,
+ .ndo_features_check = qede_features_check,
};
/* -------------------------------------------------------------------------
--
2.7.2
^ permalink raw reply related
* [PATCH v2 net-next 5/7] qed: Allow chance for fast ramrod completions
From: Manish Chopra @ 2016-10-13 11:22 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz, Yuval Mintz
In-Reply-To: <1476357771-1578-1-git-send-email-manish.chopra@qlogic.com>
From: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
Whenever a ramrod is being sent for some device configuration,
the driver is going to sleep at least 5ms between each iteration
of polling on the completion of the ramrod.
However, in almost every configuration scenario the firmware
would be able to comply and complete the ramrod in a manner of
several usecs. This is especially important in cases where there
might be a lot of sequential configurations applying to the hardware
[e.g., RoCE], in which case the existing scheme might cause some
visible user delays.
This patch changes the completion scheme - instead of immediately
starting to sleep for a 'long' period, allow the device to quickly
poll on the first iteration after a couple of usecs.
Signed-off-by: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
---
drivers/net/ethernet/qlogic/qed/qed_spq.c | 85 +++++++++++++++++++++----------
1 file changed, 59 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_spq.c b/drivers/net/ethernet/qlogic/qed/qed_spq.c
index caff415..259a615 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_spq.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_spq.c
@@ -37,7 +37,11 @@
***************************************************************************/
#define SPQ_HIGH_PRI_RESERVE_DEFAULT (1)
-#define SPQ_BLOCK_SLEEP_LENGTH (1000)
+
+#define SPQ_BLOCK_DELAY_MAX_ITER (10)
+#define SPQ_BLOCK_DELAY_US (10)
+#define SPQ_BLOCK_SLEEP_MAX_ITER (1000)
+#define SPQ_BLOCK_SLEEP_MS (5)
/***************************************************************************
* Blocking Imp. (BLOCK/EBLOCK mode)
@@ -57,53 +61,81 @@ static void qed_spq_blocking_cb(struct qed_hwfn *p_hwfn,
smp_wmb();
}
-static int qed_spq_block(struct qed_hwfn *p_hwfn,
- struct qed_spq_entry *p_ent,
- u8 *p_fw_ret)
+static int __qed_spq_block(struct qed_hwfn *p_hwfn,
+ struct qed_spq_entry *p_ent,
+ u8 *p_fw_ret, bool sleep_between_iter)
{
- int sleep_count = SPQ_BLOCK_SLEEP_LENGTH;
struct qed_spq_comp_done *comp_done;
- int rc;
+ u32 iter_cnt;
comp_done = (struct qed_spq_comp_done *)p_ent->comp_cb.cookie;
- while (sleep_count) {
- /* validate we receive completion update */
+ iter_cnt = sleep_between_iter ? SPQ_BLOCK_SLEEP_MAX_ITER
+ : SPQ_BLOCK_DELAY_MAX_ITER;
+
+ while (iter_cnt--) {
+ /* Validate we receive completion update */
smp_rmb();
if (comp_done->done == 1) {
if (p_fw_ret)
*p_fw_ret = comp_done->fw_return_code;
return 0;
}
- usleep_range(5000, 10000);
- sleep_count--;
+
+ if (sleep_between_iter)
+ msleep(SPQ_BLOCK_SLEEP_MS);
+ else
+ udelay(SPQ_BLOCK_DELAY_US);
}
+ return -EBUSY;
+}
+
+static int qed_spq_block(struct qed_hwfn *p_hwfn,
+ struct qed_spq_entry *p_ent,
+ u8 *p_fw_ret, bool skip_quick_poll)
+{
+ struct qed_spq_comp_done *comp_done;
+ int rc;
+
+ /* A relatively short polling period w/o sleeping, to allow the FW to
+ * complete the ramrod and thus possibly to avoid the following sleeps.
+ */
+ if (!skip_quick_poll) {
+ rc = __qed_spq_block(p_hwfn, p_ent, p_fw_ret, false);
+ if (!rc)
+ return 0;
+ }
+
+ /* Move to polling with a sleeping period between iterations */
+ rc = __qed_spq_block(p_hwfn, p_ent, p_fw_ret, true);
+ if (!rc)
+ return 0;
+
DP_INFO(p_hwfn, "Ramrod is stuck, requesting MCP drain\n");
rc = qed_mcp_drain(p_hwfn, p_hwfn->p_main_ptt);
- if (rc != 0)
+ if (rc) {
DP_NOTICE(p_hwfn, "MCP drain failed\n");
+ goto err;
+ }
/* Retry after drain */
- sleep_count = SPQ_BLOCK_SLEEP_LENGTH;
- while (sleep_count) {
- /* validate we receive completion update */
- smp_rmb();
- if (comp_done->done == 1) {
- if (p_fw_ret)
- *p_fw_ret = comp_done->fw_return_code;
- return 0;
- }
- usleep_range(5000, 10000);
- sleep_count--;
- }
+ rc = __qed_spq_block(p_hwfn, p_ent, p_fw_ret, true);
+ if (!rc)
+ return 0;
+ comp_done = (struct qed_spq_comp_done *)p_ent->comp_cb.cookie;
if (comp_done->done == 1) {
if (p_fw_ret)
*p_fw_ret = comp_done->fw_return_code;
return 0;
}
-
- DP_NOTICE(p_hwfn, "Ramrod is stuck, MCP drain failed\n");
+err:
+ DP_NOTICE(p_hwfn,
+ "Ramrod is stuck [CID %08x cmd %02x protocol %02x echo %04x]\n",
+ le32_to_cpu(p_ent->elem.hdr.cid),
+ p_ent->elem.hdr.cmd_id,
+ p_ent->elem.hdr.protocol_id,
+ le16_to_cpu(p_ent->elem.hdr.echo));
return -EBUSY;
}
@@ -729,7 +761,8 @@ int qed_spq_post(struct qed_hwfn *p_hwfn,
* access p_ent here to see whether it's successful or not.
* Thus, after gaining the answer perform the cleanup here.
*/
- rc = qed_spq_block(p_hwfn, p_ent, fw_return_code);
+ rc = qed_spq_block(p_hwfn, p_ent, fw_return_code,
+ p_ent->queue == &p_spq->unlimited_pending);
if (p_ent->queue == &p_spq->unlimited_pending) {
/* This is an allocated p_ent which does not need to
--
2.7.2
^ permalink raw reply related
* [PATCH v2 net-next 2/7] qede: GSO support for tunnels with outer csum
From: Manish Chopra @ 2016-10-13 11:22 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz, Manish Chopra
In-Reply-To: <1476357771-1578-1-git-send-email-manish.chopra@qlogic.com>
From: Manish Chopra <manish.chopra@caviumnetworks.com>
This patch adds GSO support for GRE and UDP tunnels
where outer checksums are enabled.
Signed-off-by: Manish Chopra <manish.chopra@caviumnetworks.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
---
drivers/net/ethernet/qlogic/qede/qede.h | 1 +
drivers/net/ethernet/qlogic/qede/qede_main.c | 26 +++++++++++++++++++++++---
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede.h b/drivers/net/ethernet/qlogic/qede/qede.h
index 28c0e9f..f50e527 100644
--- a/drivers/net/ethernet/qlogic/qede/qede.h
+++ b/drivers/net/ethernet/qlogic/qede/qede.h
@@ -320,6 +320,7 @@ struct qede_fastpath {
#define XMIT_L4_CSUM BIT(0)
#define XMIT_LSO BIT(1)
#define XMIT_ENC BIT(2)
+#define XMIT_ENC_GSO_L4_CSUM BIT(3)
#define QEDE_CSUM_ERROR BIT(0)
#define QEDE_CSUM_UNNECESSARY BIT(1)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 9866d95..7d5dc1e 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -400,8 +400,19 @@ static u32 qede_xmit_type(struct qede_dev *edev,
(ipv6_hdr(skb)->nexthdr == NEXTHDR_IPV6))
*ipv6_ext = 1;
- if (skb->encapsulation)
+ if (skb->encapsulation) {
rc |= XMIT_ENC;
+ if (skb_is_gso(skb)) {
+ unsigned short gso_type = skb_shinfo(skb)->gso_type;
+
+ if ((gso_type & SKB_GSO_UDP_TUNNEL_CSUM) ||
+ (gso_type & SKB_GSO_GRE_CSUM))
+ rc |= XMIT_ENC_GSO_L4_CSUM;
+
+ rc |= XMIT_LSO;
+ return rc;
+ }
+ }
if (skb_is_gso(skb))
rc |= XMIT_LSO;
@@ -637,6 +648,12 @@ static netdev_tx_t qede_start_xmit(struct sk_buff *skb,
if (unlikely(xmit_type & XMIT_ENC)) {
first_bd->data.bd_flags.bitfields |=
1 << ETH_TX_1ST_BD_FLAGS_TUNN_IP_CSUM_SHIFT;
+
+ if (xmit_type & XMIT_ENC_GSO_L4_CSUM) {
+ u8 tmp = ETH_TX_1ST_BD_FLAGS_TUNN_L4_CSUM_SHIFT;
+
+ first_bd->data.bd_flags.bitfields |= 1 << tmp;
+ }
hlen = qede_get_skb_hlen(skb, true);
} else {
first_bd->data.bd_flags.bitfields |=
@@ -2320,11 +2337,14 @@ static void qede_init_ndev(struct qede_dev *edev)
/* Encap features*/
hw_features |= NETIF_F_GSO_GRE | NETIF_F_GSO_UDP_TUNNEL |
- NETIF_F_TSO_ECN;
+ NETIF_F_TSO_ECN | NETIF_F_GSO_UDP_TUNNEL_CSUM |
+ NETIF_F_GSO_GRE_CSUM;
ndev->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_GRE |
- NETIF_F_GSO_UDP_TUNNEL | NETIF_F_RXCSUM;
+ NETIF_F_GSO_UDP_TUNNEL | NETIF_F_RXCSUM |
+ NETIF_F_GSO_UDP_TUNNEL_CSUM |
+ NETIF_F_GSO_GRE_CSUM;
ndev->vlan_features = hw_features | NETIF_F_RXHASH | NETIF_F_RXCSUM |
NETIF_F_HIGHDMA;
--
2.7.2
^ permalink raw reply related
* [PATCH v2 net-next 1/7] qed: Pass MAC hints to VFs
From: Manish Chopra @ 2016-10-13 11:22 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz, Yuval Mintz
In-Reply-To: <1476357771-1578-1-git-send-email-manish.chopra@qlogic.com>
From: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
Some hypervisors can support MAC hints to their VFs.
Even though we don't have such a hypervisor API in linux, we add
sufficient logic for the VF to be able to receive such hints and
set the mac accordingly - as long as the VF has not been set with
a MAC already.
Signed-off-by: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
---
drivers/net/ethernet/qlogic/qed/qed_vf.c | 4 ++--
drivers/net/ethernet/qlogic/qede/qede_main.c | 6 +++++-
include/linux/qed/qed_eth_if.h | 2 +-
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.c b/drivers/net/ethernet/qlogic/qed/qed_vf.c
index abf5bf1..f580bf4 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.c
@@ -1230,8 +1230,8 @@ static void qed_handle_bulletin_change(struct qed_hwfn *hwfn)
is_mac_exist = qed_vf_bulletin_get_forced_mac(hwfn, mac,
&is_mac_forced);
- if (is_mac_exist && is_mac_forced && cookie)
- ops->force_mac(cookie, mac);
+ if (is_mac_exist && cookie)
+ ops->force_mac(cookie, mac, !!is_mac_forced);
/* Always update link configuration according to bulletin */
qed_link_update(hwfn);
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 343038c..9866d95 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -171,10 +171,14 @@ static struct pci_driver qede_pci_driver = {
#endif
};
-static void qede_force_mac(void *dev, u8 *mac)
+static void qede_force_mac(void *dev, u8 *mac, bool forced)
{
struct qede_dev *edev = dev;
+ /* MAC hints take effect only if we haven't set one already */
+ if (is_valid_ether_addr(edev->ndev->dev_addr) && !forced)
+ return;
+
ether_addr_copy(edev->ndev->dev_addr, mac);
ether_addr_copy(edev->primary_mac, mac);
}
diff --git a/include/linux/qed/qed_eth_if.h b/include/linux/qed/qed_eth_if.h
index 33c24eb..1c77948 100644
--- a/include/linux/qed/qed_eth_if.h
+++ b/include/linux/qed/qed_eth_if.h
@@ -129,7 +129,7 @@ struct qed_tunn_params {
struct qed_eth_cb_ops {
struct qed_common_cb_ops common;
- void (*force_mac) (void *dev, u8 *mac);
+ void (*force_mac) (void *dev, u8 *mac, bool forced);
};
#ifdef CONFIG_DCB
--
2.7.2
^ 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