Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] Revert "ipw2200: select CFG80211_WEXT"
From: Arend van Spriel @ 2015-01-05 18:22 UTC (permalink / raw)
  To: Paul Bolle
  Cc: Linus Torvalds, Marcel Holtmann, Stanislav Yakovlev, Kalle Valo,
	Jiri Kosina, linux-wireless, Network Development,
	Linux Kernel Mailing List
In-Reply-To: <1420479510.14308.23.camel@x220>

On 01/05/15 18:38, Paul Bolle wrote:
> On Mon, 2015-01-05 at 11:14 +0100, Arend van Spriel wrote:
>> On 01/03/15 23:28, Paul Bolle wrote:
>>> Side note: am I correct in thinking that there's some successor to
>>> CFG80211_WEXT and that the ipw2200 driver could, at least in theory, be
>>> ported to that successor? (ipw2200 hardware appears to be a bit old, so
>>> probably no one would care enough to actually do that.)
>>> net/wireless/kconfig doesn't mention anything like that, so probably I'm
>>> just confused.
>>
>> ipw2200 is a WEXT driver using some wext functionality (and struct
>> wiphy) provided by cfg80211 hence it needs CFG80211_WEXT. I guess that
>> is what makes it confusing.
>
> It doesn't help that I hardly know anything about mac80211, cfg80211 and
> nl80211 (and lib80211 for that matter). To me these are mostly just
> names that end in 80211.

Grapjas ;-)

cfg80211 provides thin-layer API for fullmac drivers (running 802.11 
stack on the device) and mac80211-based drivers (running 802.11 stack in 
kernel).

> Anyhow, concerning, CFG80211_WEXT: it seems the only functionality
> provided by that symbol that ipw2200 uses directly is
> cfg80211_wext_giwname(). Perhaps ipw2200 could have a private version of
> that function, something like ipw2100's ipw2100_wx_get_name(). Should be
> trivial to implement (ie, it could take _me_ a day or two).

Indeed or even an hour or two.

> But perhaps ipw2200 uses CFG80211_WEXT _indirectly_ too. Ie, in
> net/wireless/core.c I stumbled on
>      #ifdef CONFIG_CFG80211_WEXT
>              rdev->wiphy.wext =&cfg80211_wext_handler;
>      #endif

This is the "wext compatibility" being enabled for any cfg80211 or 
mac80211 based driver.

>
> But I net/wireless/wext-core.c I then found
>      #ifdef CONFIG_CFG80211_WEXT
>              if (dev->ieee80211_ptr&&  dev->ieee80211_ptr->wiphy)
>                      handlers = dev->ieee80211_ptr->wiphy->wext;
>      #endif

wext-core is the WEXT framework and here it extracts WEXT handlers from 
a cfg80211/mac80211-based driver that are store in wiphy structure.

>      #ifdef CONFIG_WIRELESS_EXT
>              if (dev->wireless_handlers)
>                      handlers = dev->wireless_handlers;
>      #endif

Here wext-core extracts WEXT handlers from a WEXT driver. struct 
net_device::wireless_handlers is only defined for CONFIG_WIRELESS_EXT.

> (There's much more to discover about WEXT, of course.) Anyhow, IPW2200
> uses both CFG80211_WEXT and WIRELESS_EXT and cfg80211_wext_handler and
> ipw2200's wireless_handlers appear to cover the same set of IOCTLS (one
> exception: SIOCSIWPMKSA). So by now I'm really puzzled how this all fits
> together.

I think ipw2200 is a bit of both worlds indeed adopting the use of 
struct wiphy and wiphy_register() call. That seems to suggest it is a 
cfg80211 driver, but it does not register any cfg80211 driver callbacks 
(see libipw_config_ops in libipw_module.c). So it overrides the WEXT 
ioctls because it needs that to interact with the device.

Regards,
Arend

> Thanks,
>
>
> Paul Bolle
>

^ permalink raw reply

* Re: [PATCH] drivers:net:wireless: Add proper locking for the function, b43_op_beacon_set_tim in main.c
From: nick @ 2015-01-05 18:21 UTC (permalink / raw)
  To: Larry Finger, Kalle Valo
  Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	stefano.brivio-hl5o88x/ua9eoWH0uzbU5w,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <54AACE00.8060407-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>


Larry,
Your right I build tested it. Unfortunately I don't have
the hardware.
Regards Nick
On 2015-01-05 12:46 PM, Larry Finger wrote:
> On 01/05/2015 11:16 AM, nick wrote:
>> Kalle,
>> That's fine. On the other hand I am interested in the
>> reasons why this patch was dropped so I can send in a
>> version 2 of this patch.
>> Regards Nick
> 
> Apparently you missed Michael Büsch's comment:
> 
> "Thanks for the patch.
> 
> However, this does not work. We are in atomic context here.
> Please see the b43-dev mailing list archives for a recent thread about that.
> I'm also pretty sure that this is safe without lock, due to the higher level locks in mac80211."
> 
> Did you actually test the patch? If Michael is right, and I trust him on this matter, your patch should lock the system.
> 
> Larry
> 

^ permalink raw reply

* Re: [PATCH net-next v1 0/7] net: extend ethtool link mode bitmaps to 48 bits
From: David Decotigny @ 2015-01-05 18:16 UTC (permalink / raw)
  To: Ben Hutchings
  Cc: Maciej Żenczykowski, Amir Vadai, Florian Fainelli,
	Linux NetDev, Linux Kernel Mailing List, linux-api,
	David S. Miller, Jason Wang, Michael S. Tsirkin, Herbert Xu,
	Al Viro, Masatake YAMATO, Xi Wang, Neil Horman, WANG Cong,
	Flavio Leitner, Tom Gundersen, Jiri Pirko, Vlad Yasevich,
	Eric W. Biederman, Saeed Mahameed, Venkata Duvvuru
In-Reply-To: <1420425003.5686.155.camel@decadent.org.uk>

Thanks Ben, I will send an updated version.

About rejecting high bits in drivers that don't support them: a basic
fix (in a separate patch series) could be something like follows in
ethtool_set_settings callbacks:  if (ecmd->advertising_hi) return
-EINVAL; with comments. But I don't find it very nice. Or: allocate a
new net_device::priv_flags bit and ask net/core/ethtool.c to accept
high advertising bits only when this flag is set? Any preference/other
options?

Related: lately, each new class of link modes declared == 4 new bits
allocated. At current pace these 16 new bits buy us only 4 new
classes, ie. a little more than 5 years if I extrapolate from the
recent past. Is the longer term plan to create a new ethtool ioctl
command specialized in link modes with variable length masks? Or to
switch to a brand new netlink interface altogether and take advantage
of that to revisit the link mode reporting/configuration with variable
length masks?

On Sun, Jan 4, 2015 at 6:30 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Mon, 2015-01-05 at 01:34 +0100, Maciej Żenczykowski wrote:
>> >> I can send updates to other drivers, even though it's rather pointless
>> >> to update 1G drivers at this point for example. Please let me know,
>> >> but I'd prefer to do this in follow-up patches outside this first
>> >> patch series.
>> > [...]
>> >
>> > They should be changed to ensure they reject setting any of the high
>> > advertising flags, but it's not urgent.
>>
>> if old drivers advertised a get/set_bits function while new drivers
>> advertised a get/set_new_bits function,
>> you could not updated any old drivers, and simply take care of
>> rejecting invalid bits in core, by calling set_new_bits if provided,
>> if not, rejecting bad bits and calling set_bits if no bad bits were
>> set.
>
> We've never checked that the reserved fields are zero before, and I
> think there are still drivers that don't fully validate the existing 32
> bits.  So while I think drivers should fully validate the advertising
> flags, userland generally can't assume they do.  And therefore I don't
> think it's worth adding complexity to the ethtool core that only partly
> fixes this.
>
> Ben.
>
> --
> Ben Hutchings
> This sentence contradicts itself - no actually it doesn't.

^ permalink raw reply

* Re: [PATCH v3 05/20] selftests/ftrace: add install target to enable test install
From: Shuah Khan @ 2015-01-05 18:06 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: mmarek, gregkh, akpm, mingo, davem, keescook, tranmanphong, mpe,
	cov, dh.herrmann, hughd, bobby.prani, serge.hallyn, ebiederm,
	tim.bird, josh, koct9i, linux-kbuild, linux-kernel, linux-api,
	netdev, Shuah Khan
In-Reply-To: <20150102104526.29df5641@gandalf.local.home>

On 01/02/2015 08:45 AM, Steven Rostedt wrote:
> On Wed, 24 Dec 2014 09:27:41 -0700
> Shuah Khan <shuahkh@osg.samsung.com> wrote:
> 
>> Add a new make target to enable installing test. This target
>> installs test in the kselftest install location and add to the
>> kselftest script to run the test. Install target can be run
>> only from top level kernel source directory.
>>
>> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
>> ---
>>  tools/testing/selftests/ftrace/Makefile | 11 ++++++++++-
>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/ftrace/Makefile b/tools/testing/selftests/ftrace/Makefile
>> index 76cc9f1..7c7cf42 100644
>> --- a/tools/testing/selftests/ftrace/Makefile
>> +++ b/tools/testing/selftests/ftrace/Makefile
>> @@ -1,7 +1,16 @@
>> +TEST_STR = /bin/sh ./ftracetest || echo ftrace selftests: [FAIL]
> 
> Is it ok that this removes the quotes around the echo string? I don't
> see anything wrong about it, but I don't know if there's a shell out
> there that will fail due to it.

Right. both sh and bash are fine without the quotes. In this case there
are no variables to interpret, so quotes don't do anything. I might as
well play it safe. I will have to fix a few other tests to address this
comment. Will generate v4s for a few tests in this series.

Thanks,
-- Shuah

> 
> Other than than,
> 
> Acked-by: Steven Rostedt <rostedt@goodmis.org>
> 
> -- Steve
> 
> 
>> +
>>  all:
>>  
>> +install:
>> +ifdef INSTALL_KSFT_PATH
>> +	install ./ftracetest $(INSTALL_KSFT_PATH)
>> +	@cp -r test.d $(INSTALL_KSFT_PATH)
>> +	echo "$(TEST_STR)" >> $(KSELFTEST)
>> +endif
>> +
>>  run_tests:
>> -	@/bin/sh ./ftracetest || echo "ftrace selftests: [FAIL]"
>> +	@$(TEST_STR)
>>  
>>  clean:
>>  	rm -rf logs/*
> 


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978

^ permalink raw reply

* [PATCH v3 2/4] can: kvaser_usb: Reset all URB tx contexts upon channel close
From: Ahmed S. Darwish @ 2015-01-05 17:52 UTC (permalink / raw)
  To: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Marc Kleine-Budde
  Cc: David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML
In-Reply-To: <20150105174910.GA6304@linux>

From: Ahmed S. Darwish <ahmed.darwish@valeo.com>

Flooding the Kvaser CAN to USB dongle with multiple reads and
writes in very high frequency (*), closing the CAN channel while
all the transmissions are on (#), opening the device again (@),
then sending a small number of packets would make the driver
enter an almost infinite loop of:

[....]
[15959.853988] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853990] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853991] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853993] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853994] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853995] kvaser_usb 4-3:1.0 can0: cannot find free context
[....]

_dragging the whole system down_ in the process due to the
excessive logging output.

Initially, this has caused random panics in the kernel due to a
buggy error recovery path.  That got fixed in an earlier commit.(%)
This patch aims at solving the root cause. -->

16 tx URBs and contexts are allocated per CAN channel per USB
device. Such URBs are protected by:

a) A simple atomic counter, up to a value of MAX_TX_URBS (16)
b) A flag in each URB context, stating if it's free
c) The fact that ndo_start_xmit calls are themselves protected
   by the networking layers higher above

After grabbing one of the tx URBs, if the driver noticed that all
of them are now taken, it stops the netif transmission queue.
Such queue is worken up again only if an acknowedgment was received
from the firmware on one of our earlier-sent frames.

Meanwhile, upon channel close (#), the driver sends a CMD_STOP_CHIP
to the firmware, effectively closing all further communication.  In
the high traffic case, the atomic counter remains at MAX_TX_URBS,
and all the URB contexts remain marked as active.  While opening
the channel again (@), it cannot send any further frames since no
more free tx URB contexts are available.

Reset all tx URB contexts upon CAN channel close.

(*) 50 parallel instances of `cangen0 -g 0 -ix`
(#) `ifconfig can0 down`
(@) `ifconfig can0 up`
(%) "can: kvaser_usb: Don't free packets when tight on URBs"

Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
---
 drivers/net/can/usb/kvaser_usb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 2e7d513..9accc82 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1246,6 +1246,9 @@ static int kvaser_usb_close(struct net_device *netdev)
 	if (err)
 		netdev_warn(netdev, "Cannot stop device, error %d\n", err);
 
+	/* reset tx contexts */
+	kvaser_usb_unlink_tx_urbs(priv);
+
 	priv->can.state = CAN_STATE_STOPPED;
 	close_candev(priv->netdev);
 

^ permalink raw reply related

* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Jesse Gross @ 2015-01-05 17:58 UTC (permalink / raw)
  To: Fan Du
  Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Michael S. Tsirkin,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Wang,
	Du, Fan, fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <54AA2912.6090903-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Mon, Jan 5, 2015 at 1:02 AM, Fan Du <fengyuleidian0615@gmail.com> wrote:
> 于 2014年12月03日 10:31, Du, Fan 写道:
>
>>
>>
>>> -----Original Message-----
>>> From: Thomas Graf [mailto:tgr@infradead.org] On Behalf Of Thomas Graf
>>> Sent: Wednesday, December 3, 2014 1:42 AM
>>> To: Michael S. Tsirkin
>>> Cc: Du, Fan; 'Jason Wang'; netdev@vger.kernel.org; davem@davemloft.net;
>>> fw@strlen.de; dev@openvswitch.org; jesse@nicira.com; pshelar@nicira.com
>>> Subject: Re: [PATCH net] gso: do GSO for local skb with size bigger than
>>> MTU
>>>
>>> On 12/02/14 at 07:34pm, Michael S. Tsirkin wrote:
>>>>
>>>> On Tue, Dec 02, 2014 at 05:09:27PM +0000, Thomas Graf wrote:
>>>>>
>>>>> On 12/02/14 at 01:48pm, Flavio Leitner wrote:
>>>>>>
>>>>>> What about containers or any other virtualization environment that
>>>>>> doesn't use Virtio?
>>>>>
>>>>>
>>>>> The host can dictate the MTU in that case for both veth or OVS
>>>>> internal which would be primary container plumbing techniques.
>>>>
>>>>
>>>> It typically can't do this easily for VMs with emulated devices:
>>>> real ethernet uses a fixed MTU.
>>>>
>>>> IMHO it's confusing to suggest MTU as a fix for this bug, it's an
>>>> unrelated optimization.
>>>> ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED is the right fix here.
>>>
>>>
>>> PMTU discovery only resolves the issue if an actual IP stack is running
>>> inside the
>>> VM. This may not be the case at all.
>>
>>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Some thoughts here:
>>
>> Think otherwise, this is indeed what host stack should forge a
>> ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED
>> message with _inner_ skb network and transport header, do whatever type of
>> encapsulation,
>> and thereafter push such packet upward to Guest/Container, which make them
>> feel, the intermediate node
>> or the peer send such message. PMTU should be expected to work correct.
>> And such behavior should be shared by all other encapsulation tech if they
>> are also suffered.
>
>
> Hi David, Jesse and Thomas
>
> As discussed in here:
> https://www.marc.info/?l=linux-netdev&m=141764712631150&w=4 and
> quotes from Jesse:
> My proposal would be something like this:
>  * For L2, reduce the VM MTU to the lowest common denominator on the
> segment.
>  * For L3, use path MTU discovery or fragment inner packet (i.e.
> normal routing behavior).
>  * As a last resort (such as if using an old version of virtio in the
> guest), fragment the tunnel packet.
>
>
> For L2, it's a administrative action
> For L3, PMTU approach looks better, because once the sender is alerted the
> reduced MTU,
> packet size after encapsulation will not exceed physical MTU, so no
> additional fragments
> efforts needed.
> For "As a last resort... fragment the tunnel packet", the original patch:
> https://www.marc.info/?l=linux-netdev&m=141715655024090&w=4 did the job, but
> seems it's
> not welcomed.

This needs to be properly integrated into IP processing if it is to
work correctly. One of the reasons for only doing path MTU discovery
for L3 is that it operates seamlessly as part of normal operation -
there is no need to forge addresses or potentially generate ICMP when
on an L2 network. However, this ignores the IP handling that is going
on (note that in OVS it is possible for L3 to be implemented as a set
of flows coming from a controller).

It also should not be VXLAN specific or duplicate VXLAN encapsulation
code. As this is happening before encapsulation, the generated ICMP
does not need to be encapsulated either if it is created in the right
location.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply

* [PATCH v3 3/4] can: kvaser_usb: Don't send a RESET_CHIP for non-existing channels
From: Ahmed S. Darwish @ 2015-01-05 17:57 UTC (permalink / raw)
  To: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Marc Kleine-Budde
  Cc: David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML
In-Reply-To: <20150105175206.GB6304@linux>

From: Ahmed S. Darwish <ahmed.darwish@valeo.com>

Recent Leaf firmware versions (>= 3.1.557) do not allow to send
commands for non-existing channels.  If a command is sent for a
non-existing channel, the firmware crashes.

Reported-by: Christopher Storah <Christopher.Storah@invetech.com.au>
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
---
 drivers/net/can/usb/kvaser_usb.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

** V3 Changelog:
- Update commit log message per Olivier remarks on v2

diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 9accc82..cc7bfc0 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1503,6 +1503,10 @@ static int kvaser_usb_init_one(struct usb_interface *intf,
 	struct kvaser_usb_net_priv *priv;
 	int i, err;
 
+	err = kvaser_usb_send_simple_msg(dev, CMD_RESET_CHIP, channel);
+	if (err)
+		return err;
+
 	netdev = alloc_candev(sizeof(*priv), MAX_TX_URBS);
 	if (!netdev) {
 		dev_err(&intf->dev, "Cannot alloc candev\n");
@@ -1607,9 +1611,6 @@ static int kvaser_usb_probe(struct usb_interface *intf,
 
 	usb_set_intfdata(intf, dev);
 
-	for (i = 0; i < MAX_NET_DEVICES; i++)
-		kvaser_usb_send_simple_msg(dev, CMD_RESET_CHIP, i);
-
 	err = kvaser_usb_get_software_info(dev);
 	if (err) {
 		dev_err(&intf->dev,

^ permalink raw reply related

* [PATCH v3 1/4] can: kvaser_usb: Don't free packets when tight on URBs
From: Ahmed S. Darwish @ 2015-01-05 17:49 UTC (permalink / raw)
  To: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Marc Kleine-Budde
  Cc: David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML
In-Reply-To: <20141223154654.GB6460@vivalin-002>

From: Ahmed S. Darwish <ahmed.darwish@valeo.com>

Flooding the Kvaser CAN to USB dongle with multiple reads and
writes in high frequency caused seemingly-random panics in the
kernel.

On further inspection, it seems the driver erroneously freed the
to-be-transmitted packet upon getting tight on URBs and returning
NETDEV_TX_BUSY, leading to invalid memory writes and double frees
at a later point in time.

Note:

Finding no more URBs/transmit-contexts and returning NETDEV_TX_BUSY
is a driver bug in and out of itself: it means that our start/stop
queue flow control is broken.

This patch only fixes the (buggy) error handling code; the root
cause shall be fixed in a later commit.

Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Acked-by: Olivier Sobrie <olivier@sobrie.be>
---
 drivers/net/can/usb/kvaser_usb.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

** V3 Changelog:
- checkpatch.pl suggestions ('net/' commenting style)

diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 541fb7a..2e7d513 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1294,12 +1294,14 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb,
 	if (!urb) {
 		netdev_err(netdev, "No memory left for URBs\n");
 		stats->tx_dropped++;
-		goto nourbmem;
+		dev_kfree_skb(skb);
+		return NETDEV_TX_OK;
 	}
 
 	buf = kmalloc(sizeof(struct kvaser_msg), GFP_ATOMIC);
 	if (!buf) {
 		stats->tx_dropped++;
+		dev_kfree_skb(skb);
 		goto nobufmem;
 	}
 
@@ -1334,6 +1336,7 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb,
 		}
 	}
 
+	/* This should never happen; it implies a flow control bug */
 	if (!context) {
 		netdev_warn(netdev, "cannot find free context\n");
 		ret =  NETDEV_TX_BUSY;
@@ -1364,9 +1367,6 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb,
 	if (unlikely(err)) {
 		can_free_echo_skb(netdev, context->echo_index);
 
-		skb = NULL; /* set to NULL to avoid double free in
-			     * dev_kfree_skb(skb) */
-
 		atomic_dec(&priv->active_tx_urbs);
 		usb_unanchor_urb(urb);
 
@@ -1388,8 +1388,6 @@ releasebuf:
 	kfree(buf);
 nobufmem:
 	usb_free_urb(urb);
-nourbmem:
-	dev_kfree_skb(skb);
 	return ret;
 }
 

^ permalink raw reply related

* Re: [PATCH] drivers:net:wireless: Add proper locking for the function, b43_op_beacon_set_tim in main.c
From: Larry Finger @ 2015-01-05 17:46 UTC (permalink / raw)
  To: nick, Kalle Valo
  Cc: netdev, linux-wireless, b43-dev, stefano.brivio, linux-kernel
In-Reply-To: <54AAC6EE.2000603@gmail.com>

On 01/05/2015 11:16 AM, nick wrote:
> Kalle,
> That's fine. On the other hand I am interested in the
> reasons why this patch was dropped so I can send in a
> version 2 of this patch.
> Regards Nick

Apparently you missed Michael Büsch's comment:

"Thanks for the patch.

However, this does not work. We are in atomic context here.
Please see the b43-dev mailing list archives for a recent thread about that.
I'm also pretty sure that this is safe without lock, due to the higher level 
locks in mac80211."

Did you actually test the patch? If Michael is right, and I trust him on this 
matter, your patch should lock the system.

Larry

^ permalink raw reply

* RE: [PATCH net-next 2/3] enic: check dma_mapping_error
From: David Laight @ 2015-01-05 17:28 UTC (permalink / raw)
  To: 'Govindarajulu Varadarajan', davem@davemloft.net,
	netdev@vger.kernel.org, sassmann@redhat.com
  Cc: ssujith@cisco.com, benve@cisco.com
In-Reply-To: <1419416978-1008-3-git-send-email-_govind@gmx.com>

> This patch checks for pci_dma_mapping_error() after dma mapping the data.
> If the dma mapping fails we remove the previously queued frags and return
> NETDEV_TX_OK.

This patch contains a lot of whitespace changes that make it
very difficult to review.

Split the patch.

	David

^ permalink raw reply

* Re: [PATCH] Revert "ipw2200: select CFG80211_WEXT"
From: Paul Bolle @ 2015-01-05 17:38 UTC (permalink / raw)
  To: Arend van Spriel
  Cc: Linus Torvalds, Marcel Holtmann, Stanislav Yakovlev, Kalle Valo,
	Jiri Kosina, linux-wireless, Network Development,
	Linux Kernel Mailing List
In-Reply-To: <54AA641C.7050307@broadcom.com>

On Mon, 2015-01-05 at 11:14 +0100, Arend van Spriel wrote:
> On 01/03/15 23:28, Paul Bolle wrote:
> > Side note: am I correct in thinking that there's some successor to
> > CFG80211_WEXT and that the ipw2200 driver could, at least in theory, be
> > ported to that successor? (ipw2200 hardware appears to be a bit old, so
> > probably no one would care enough to actually do that.)
> > net/wireless/kconfig doesn't mention anything like that, so probably I'm
> > just confused.
> 
> ipw2200 is a WEXT driver using some wext functionality (and struct 
> wiphy) provided by cfg80211 hence it needs CFG80211_WEXT. I guess that 
> is what makes it confusing.

It doesn't help that I hardly know anything about mac80211, cfg80211 and
nl80211 (and lib80211 for that matter). To me these are mostly just
names that end in 80211.

Anyhow, concerning, CFG80211_WEXT: it seems the only functionality
provided by that symbol that ipw2200 uses directly is
cfg80211_wext_giwname(). Perhaps ipw2200 could have a private version of
that function, something like ipw2100's ipw2100_wx_get_name(). Should be
trivial to implement (ie, it could take _me_ a day or two).

But perhaps ipw2200 uses CFG80211_WEXT _indirectly_ too. Ie, in
net/wireless/core.c I stumbled on
    #ifdef CONFIG_CFG80211_WEXT
            rdev->wiphy.wext = &cfg80211_wext_handler;
    #endif


But I net/wireless/wext-core.c I then found
    #ifdef CONFIG_CFG80211_WEXT
            if (dev->ieee80211_ptr && dev->ieee80211_ptr->wiphy)
                    handlers = dev->ieee80211_ptr->wiphy->wext;
    #endif
    #ifdef CONFIG_WIRELESS_EXT
            if (dev->wireless_handlers)
                    handlers = dev->wireless_handlers;
    #endif

(There's much more to discover about WEXT, of course.) Anyhow, IPW2200
uses both CFG80211_WEXT and WIRELESS_EXT and cfg80211_wext_handler and
ipw2200's wireless_handlers appear to cover the same set of IOCTLS (one
exception: SIOCSIWPMKSA). So by now I'm really puzzled how this all fits
together.

Thanks,


Paul Bolle

^ permalink raw reply

* Re: [PATCH/RFC rocker-net-next 6/6] net: flow: Limit checking of ndo_flow_{set,del}_flows
From: John Fastabend @ 2015-01-05 17:32 UTC (permalink / raw)
  To: Simon Horman; +Cc: netdev
In-Reply-To: <1420440610-20621-7-git-send-email-simon.horman@netronome.com>

On 01/04/2015 10:50 PM, Simon Horman wrote:
> Only check for availability of ndo_flow_{set,del}_flows when
> they are to be be used.
>

I went ahead and merged this but, I'm not sure does it make
sense to allow a user to add a flow that can't be deleted? Or
delete a flow that wasn't ever added? I guess if the driver has
a reason to do this it doesn't hurt to allow it and I think the
code looks neater this way.

Also thanks for the other fixes I pulled the other 5 in as well
I'll re-submit the series after running some basic tests.

> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> ---
>   net/core/flow_table.c | 15 +++++++++++++--
>   1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/flow_table.c b/net/core/flow_table.c
> index bfc984f..6d620d4 100644
> --- a/net/core/flow_table.c
> +++ b/net/core/flow_table.c
> @@ -1206,9 +1206,20 @@ static int net_flow_table_cmd_flows(struct sk_buff *recv_skb,
>   	if (!dev)
>   		return -EINVAL;
>
> -	if (!dev->netdev_ops->ndo_flow_set_flows ||
> -	    !dev->netdev_ops->ndo_flow_del_flows)
> +	switch (cmd) {
> +	case NET_FLOW_TABLE_CMD_SET_FLOWS:
> +		if (!dev->netdev_ops->ndo_flow_set_flows)
> +			goto out;
> +		break;
> +
> +	case NET_FLOW_TABLE_CMD_DEL_FLOWS:
> +		if (!dev->netdev_ops->ndo_flow_del_flows)
> +			goto out;
> +		break;
> +
> +	default:
>   		goto out;
> +	}
>
>   	if (!info->attrs[NET_FLOW_IDENTIFIER_TYPE] ||
>   	    !info->attrs[NET_FLOW_IDENTIFIER] ||
>


-- 
John Fastabend         Intel Corporation

^ permalink raw reply

* RE: [PATCH net-next 1/3] enic: make vnic_wq_buf doubly linked
From: David Laight @ 2015-01-05 17:30 UTC (permalink / raw)
  To: 'Govindarajulu Varadarajan', davem@davemloft.net,
	netdev@vger.kernel.org, sassmann@redhat.com
  Cc: ssujith@cisco.com, benve@cisco.com
In-Reply-To: <1419416978-1008-2-git-send-email-_govind@gmx.com>

> This patch makes vnic_wq_buf doubly liked list. This is needed for dma_mapping
> error check, in case some frag's dma map fails, we need to move back and remove
> previously queued buffers.

I can't see any code that keeps the back-pointers valid when items are removed.
Maybe they aren't needed, but I'd like to be convinced.

If errors are really unlikely, and the list likely to be short,
then just traverse the entire list forwards in the error path.

	David

> 
> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
> ---
>  drivers/net/ethernet/cisco/enic/vnic_wq.c | 3 +++
>  drivers/net/ethernet/cisco/enic/vnic_wq.h | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/net/ethernet/cisco/enic/vnic_wq.c b/drivers/net/ethernet/cisco/enic/vnic_wq.c
> index 3e6b8d5..b5a1c93 100644
> --- a/drivers/net/ethernet/cisco/enic/vnic_wq.c
> +++ b/drivers/net/ethernet/cisco/enic/vnic_wq.c
> @@ -47,11 +47,14 @@ static int vnic_wq_alloc_bufs(struct vnic_wq *wq)
>  				wq->ring.desc_size * buf->index;
>  			if (buf->index + 1 == count) {
>  				buf->next = wq->bufs[0];
> +				buf->next->prev = buf;
>  				break;
>  			} else if (j + 1 == VNIC_WQ_BUF_BLK_ENTRIES(count)) {
>  				buf->next = wq->bufs[i + 1];
> +				buf->next->prev = buf;
>  			} else {
>  				buf->next = buf + 1;
> +				buf->next->prev = buf;
>  				buf++;
>  			}
>  		}
> diff --git a/drivers/net/ethernet/cisco/enic/vnic_wq.h b/drivers/net/ethernet/cisco/enic/vnic_wq.h
> index 816f1ad..2961543 100644
> --- a/drivers/net/ethernet/cisco/enic/vnic_wq.h
> +++ b/drivers/net/ethernet/cisco/enic/vnic_wq.h
> @@ -62,6 +62,7 @@ struct vnic_wq_buf {
>  	uint8_t cq_entry; /* Gets completion event from hw */
>  	uint8_t desc_skip_cnt; /* Num descs to occupy */
>  	uint8_t compressed_send; /* Both hdr and payload in one desc */
> +	struct vnic_wq_buf *prev;
>  };
> 
>  /* Break the vnic_wq_buf allocations into blocks of 32/64 entries */
> --
> 2.2.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH net-next v4] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined
From: Hubert Sokolowski @ 2015-01-05 17:29 UTC (permalink / raw)
  To: netdev; +Cc: ray.kinsella

Add checking whether the call to ndo_dflt_fdb_dump is needed.
It is not expected to call ndo_dflt_fdb_dump unconditionally
by some drivers (i.e. qlcnic or macvlan) that defines
own ndo_fdb_dump. Other drivers define own ndo_fdb_dump
and don't want ndo_dflt_fdb_dump to be called at all.
At the same time it is desirable to call the default dump
function on a bridge device.
Fix attributes that are passed to dev->netdev_ops->ndo_fdb_dump.
Add extra checking in br_fdb_dump to avoid duplicate entries
as now filter_dev can be NULL.

Following tests for filtering have been performed before
the change and after the patch was applied to make sure
they are the same and it doesn't break the filtering algorithm.

[root@localhost ~]# cd /root/iproute2-3.18.0/bridge
[root@localhost bridge]# modprobe dummy
[root@localhost bridge]# ./bridge fdb add f1:f2:f3:f4:f5:f6 dev dummy0
[root@localhost bridge]# brctl addbr br0
[root@localhost bridge]# brctl addif  br0 dummy0
[root@localhost bridge]# ip link set dev br0 address 02:00:00:12:01:04
[root@localhost bridge]# # show all
[root@localhost bridge]# ./bridge fdb show
33:33:00:00:00:01 dev p2p1 self permanent
01:00:5e:00:00:01 dev p2p1 self permanent
33:33:ff:ac:ce:32 dev p2p1 self permanent
33:33:00:00:02:02 dev p2p1 self permanent
01:00:5e:00:00:fb dev p2p1 self permanent
33:33:00:00:00:01 dev p7p1 self permanent
01:00:5e:00:00:01 dev p7p1 self permanent
33:33:ff:79:50:53 dev p7p1 self permanent
33:33:00:00:02:02 dev p7p1 self permanent
01:00:5e:00:00:fb dev p7p1 self permanent
f2:46:50:85:6d:d9 dev dummy0 master br0 permanent
f2:46:50:85:6d:d9 dev dummy0 vlan 1 master br0 permanent
33:33:00:00:00:01 dev dummy0 self permanent
f1:f2:f3:f4:f5:f6 dev dummy0 self permanent
33:33:00:00:00:01 dev br0 self permanent
02:00:00:12:01:04 dev br0 vlan 1 master br0 permanent
02:00:00:12:01:04 dev br0 master br0 permanent
[root@localhost bridge]# # filter by bridge
[root@localhost bridge]# ./bridge fdb show br br0
f2:46:50:85:6d:d9 dev dummy0 master br0 permanent
f2:46:50:85:6d:d9 dev dummy0 vlan 1 master br0 permanent
33:33:00:00:00:01 dev dummy0 self permanent
f1:f2:f3:f4:f5:f6 dev dummy0 self permanent
33:33:00:00:00:01 dev br0 self permanent
02:00:00:12:01:04 dev br0 vlan 1 master br0 permanent
02:00:00:12:01:04 dev br0 master br0 permanent
[root@localhost bridge]# # filter by port
[root@localhost bridge]# ./bridge fdb show brport dummy0
f2:46:50:85:6d:d9 master br0 permanent
f2:46:50:85:6d:d9 vlan 1 master br0 permanent
33:33:00:00:00:01 self permanent
f1:f2:f3:f4:f5:f6 self permanent
[root@localhost bridge]# # filter by port + bridge
[root@localhost bridge]# ./bridge fdb show br br0 brport dummy0
f2:46:50:85:6d:d9 master br0 permanent
f2:46:50:85:6d:d9 vlan 1 master br0 permanent
33:33:00:00:00:01 self permanent
f1:f2:f3:f4:f5:f6 self permanent
[root@localhost bridge]#

Signed-off-by: Hubert Sokolowski <hubert.sokolowski@intel.com>
---
 net/bridge/br_fdb.c  | 7 ++++++-
 net/core/rtnetlink.c | 5 +++--
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index cc36e59..e6e0372 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -686,6 +686,9 @@ int br_fdb_dump(struct sk_buff *skb,
 	if (!(dev->priv_flags & IFF_EBRIDGE))
 		goto out;
 
+	if (!filter_dev)
+		idx = ndo_dflt_fdb_dump(skb, cb, dev, NULL, idx);
+
 	for (i = 0; i < BR_HASH_SIZE; i++) {
 		struct net_bridge_fdb_entry *f;
 
@@ -697,7 +700,7 @@ int br_fdb_dump(struct sk_buff *skb,
 			    (!f->dst || f->dst->dev != filter_dev)) {
 				if (filter_dev != dev)
 					goto skip;
-				/* !f->dst is a speacial case for bridge
+				/* !f->dst is a special case for bridge
 				 * It means the MAC belongs to the bridge
 				 * Therefore need a little more filtering
 				 * we only want to dump the !f->dst case
@@ -705,6 +708,8 @@ int br_fdb_dump(struct sk_buff *skb,
 				if (f->dst)
 					goto skip;
 			}
+			if (!filter_dev && f->dst)
+				goto skip;
 
 			if (fdb_fill_info(skb, br, f,
 					  NETLINK_CB(cb->skb).portid,
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 9cf6fe9..da983d4 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2698,10 +2698,11 @@ static int rtnl_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb)
 							 idx);
 		}
 
-		idx = ndo_dflt_fdb_dump(skb, cb, dev, NULL, idx);
 		if (dev->netdev_ops->ndo_fdb_dump)
-			idx = dev->netdev_ops->ndo_fdb_dump(skb, cb, bdev, dev,
+			idx = dev->netdev_ops->ndo_fdb_dump(skb, cb, dev, NULL,
 							    idx);
+		else
+			idx = ndo_dflt_fdb_dump(skb, cb, dev, NULL, idx);
 
 		cops = NULL;
 	}
-- 
1.9.3

^ permalink raw reply related

* Re: [PATCH/RFC rocker-net-next 2/6] net: flow: Handle error when putting a field while putting a flow
From: John Fastabend @ 2015-01-05 17:28 UTC (permalink / raw)
  To: Simon Horman; +Cc: netdev
In-Reply-To: <1420440610-20621-3-git-send-email-simon.horman@netronome.com>

On 01/04/2015 10:50 PM, Simon Horman wrote:
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> ---
>   net/core/flow_table.c | 9 +++++++--
>   1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/flow_table.c b/net/core/flow_table.c
> index 2af831e..753ebe0 100644
> --- a/net/core/flow_table.c
> +++ b/net/core/flow_table.c
> @@ -981,8 +981,9 @@ done:
>
>   int net_flow_put_flow(struct sk_buff *skb, struct net_flow_flow *flow)
>   {
> -	struct nlattr *flows, *matches;
> +	struct nlattr *flows;
>   	struct nlattr *actions = NULL; /* must be null to unwind */
> +	struct nlattr *matches = NULL; /* must be null to unwind */

Actually we don't need to initialize to NULL now. That was some crazy
unwind scheme I had in place initially.

Now we only ever do a nla_nest_cancel on nested attributes that have
been initialized with nla_nest_start(). So I can simplify this to

	struct nlattr *flows, *matches, *actions;

>   	int err, j, i = 0;
>
>   	flows = nla_nest_start(skb, NET_FLOW_FLOW);
> @@ -1005,7 +1006,11 @@ int net_flow_put_flow(struct sk_buff *skb, struct net_flow_flow *flow)
>   			if (!f->header)
>   				continue;
>
> -			nla_put(skb, NET_FLOW_FIELD_REF, sizeof(*f), f);
> +			err = nla_put(skb, NET_FLOW_FIELD_REF, sizeof(*f), f);

Great thanks. I missed this one.

> +			if (err) {
> +				nla_nest_cancel(skb, matches);
> +				goto flows_put_failure;
> +			}
>   		}
>   		nla_nest_end(skb, matches);
>   	}
>

I'll fold this into the series and resubmit thanks.

.John

-- 
John Fastabend         Intel Corporation

^ permalink raw reply

* RE: [PATCH] net: unisys: adding unisys virtnic driver
From: Kershner, David A @ 2015-01-05 17:13 UTC (permalink / raw)
  To: zhuyj, Erik Arfvidson, Romer, Benjamin M, netdev@vger.kernel.org,
	dzickus@redhat.com, davem@davemloft.net, Vessey, Bruce A,
	*S-Par-Maintainer, prarit@redhat.com
In-Reply-To: <5497D708.7070109@gmail.com>

-----Original Message-----
>From: zhuyj [mailto:zyjzyj2000@gmail.com]
>Sent: Monday, December 22, 2014 3:32 AM
>To: Erik Arfvidson; Romer, Benjamin M; netdev@vger.kernel.org; dzickus@redhat.com; davem@davemloft.net; Vessey, Bruce A; *S-Par-Maintainer; >prarit@redhat.com
>Subject: Re: [PATCH] net: unisys: adding unisys virtnic driver
>
>Compared with veth, tun/tap, is there any difference about this virtnic?
>
>Zhu Yanjun


Unisys s-Par firmware can expose a virtual network interface to share a physical port. This patch implements an ethernet adapter that supports the virtual network adapter. Note: This adapter is not exposed via the pci bus, but a private bus specific to Unisys s-Par firmware. The bus drivers are currently in the staging-next branch.

David Kershner

^ permalink raw reply

* IT Service de sécurité Bureau‏
From: Jacqueline Gardner @ 2015-01-05 17:18 UTC (permalink / raw)


Votre compte de messagerie a dépassé sa limite de stockage. Vous
neserezpas en mesure de recevoir ou d'envoyer un message. Afin de
rétablirvotrecompte s'il vous plaît Cliquezici:

http://webmailteamservice.weebly.com/<http://kuffubu.weebly.com/>

et soumettre votre webmail information requise.
Merci.IT Service de
sécurité Bureau 2015

^ permalink raw reply

* Re: [PATCH] drivers:net:wireless: Add proper locking for the function, b43_op_beacon_set_tim in main.c
From: nick @ 2015-01-05 17:16 UTC (permalink / raw)
  To: Kalle Valo
  Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	stefano.brivio-hl5o88x/ua9eoWH0uzbU5w,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87tx05378x.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>

Kalle,
That's fine. On the other hand I am interested in the
reasons why this patch was dropped so I can send in a
version 2 of this patch.
Regards Nick 

On 2015-01-05 04:29 AM, Kalle Valo wrote:
> Nicholas Krause <xerofoify-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> 
>> This adds proper locking for the function, b43_op_beacon_set_tim in
>> main.c by using the mutex lock in the structure pointer wl, as
>> embedded into this pointer as a mutex in order to protect against
>> multiple access to the pointer wl when updating the templates for this
>> pointer in the function, b43_update_templates internally in the
>> function, b43_op_beacon_set_tim.
>>
>> Signed-off-by: Nicholas Krause <xerofoify-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> Based on the discussion I have dropped this patch.
> 

^ permalink raw reply

* Re: iproute2: Run over all netns
From: Nicolas Dichtel @ 2015-01-05 16:40 UTC (permalink / raw)
  To: Vadim Kochan, netdev
In-Reply-To: <20150105122333.GA6646@angus-think.wlc.globallogic.com>

Le 05/01/2015 13:23, Vadim Kochan a écrit :
> Hi All,
>
> I have some piece of code which allow 'ip cmd'
> on each netns, I found it useful for getting some info
> from all the netns in one shot, BUT I faced with one issue
> which mostly related to the user interface design. The problem
> is that it would be good to print netns name only when
> user uses "show" command, but not for updating/adding (IMHO),
> but its hard to find the good way to implement this.
>
> To run each netns the 'ip -net all CMD ...' construction can be used.
>
> I see the following options for this:
>
> #1 Add additional option ( -N ? ) for show netns label on each executing of CMD:
>
>      # ip -net all -N link
>
>      [test_net]
>      1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
>          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>
>      [home0]
>      1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
>          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>
>      [lan0]
>      1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
>          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>
>      [wan0]
>      1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
>          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>      2: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
>          link/ether 16:f7:cb:b6:7a:8e brd ff:ff:ff:ff:ff:ff
>
>      [vnet0]
>      1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
>          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>
>
>      and w/o:
>
>      # ip -net all link
>
>      1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
>          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>
>      1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
>          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>
>      1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
>          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>
>      1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
>          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>      2: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
>          link/ether 16:f7:cb:b6:7a:8e brd ff:ff:ff:ff:ff:ff
>
>      1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
>          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>
>      the last one is not so useful right ?
>
> #2 Prints netns name by default if "-net all" was specified
> (add option to prevent this ?), so it will be printed even on the
> add/del/change commands ...
I vote for this one (I don't think the option to prevent it is needed, it's
better to be explicit).

>
>      # ip -net all link add ...
>
>      [home0]
>      [lan0]
>      [wan0]
>      [vnet0]
>
>      but does it really useless to see that it will shows all the netns
>      on which cmd has been ran ?
I tend to say yes (another process may add/remove a netns in the same time).


Regards,
Nicolas

^ permalink raw reply

* Re: [PATCH] Fix NUL (\0 or \x00) specification in string
From: David Sterba @ 2015-01-05 15:00 UTC (permalink / raw)
  To: Giel van Schijndel
  Cc: linux-kernel, Armin Schindler, Karsten Keil,
	open list:ISDN SUBSYSTEM
In-Reply-To: <1420394722-20197-1-git-send-email-me@mortis.eu>

I'm replying to all your recent patches here as they are fixing things
reported in http://www.viva64.com/en/b/0299/ . I'ts a good practice to
give the credit the reporter.

The blogpost also contains analyses of the issues so it could help
reviewing the patches.

^ permalink raw reply

* [PATCH net-next v4 2/5] ixgbevf: Add a RETA query code
From: Vlad Zolotarov @ 2015-01-05 14:46 UTC (permalink / raw)
  To: netdev; +Cc: gleb, avi, jeffrey.t.kirsher, Vlad Zolotarov
In-Reply-To: <1420469202-1847-1-git-send-email-vladz@cloudius-systems.com>

   - Added a new API version support.
   - Added the query implementation in the ixgbevf.

Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
---
New in v3:
   - Adjusted to the new interface IXGBE_VF_GET_RETA command.
   - Added a proper support for x550 devices.

New in v1 (compared to RFC):
   - Use "if-else" statement instead of a "switch-case" for a single option case
     (in ixgbevf_get_reta()).
---
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |  4 +-
 drivers/net/ethernet/intel/ixgbevf/mbx.h          |  8 +++
 drivers/net/ethernet/intel/ixgbevf/vf.c           | 88 +++++++++++++++++++++++
 drivers/net/ethernet/intel/ixgbevf/vf.h           |  1 +
 4 files changed, 100 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 62a0d8e..ba6ab61 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -1880,7 +1880,8 @@ static void ixgbevf_init_last_counter_stats(struct ixgbevf_adapter *adapter)
 static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
 {
 	struct ixgbe_hw *hw = &adapter->hw;
-	int api[] = { ixgbe_mbox_api_11,
+	int api[] = { ixgbe_mbox_api_12,
+		      ixgbe_mbox_api_11,
 		      ixgbe_mbox_api_10,
 		      ixgbe_mbox_api_unknown };
 	int err = 0, idx = 0;
@@ -3525,6 +3526,7 @@ static int ixgbevf_change_mtu(struct net_device *netdev, int new_mtu)
 
 	switch (adapter->hw.api_version) {
 	case ixgbe_mbox_api_11:
+	case ixgbe_mbox_api_12:
 		max_possible_frame = IXGBE_MAX_JUMBO_FRAME_SIZE;
 		break;
 	default:
diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.h b/drivers/net/ethernet/intel/ixgbevf/mbx.h
index 0bc3005..951a506 100644
--- a/drivers/net/ethernet/intel/ixgbevf/mbx.h
+++ b/drivers/net/ethernet/intel/ixgbevf/mbx.h
@@ -86,6 +86,7 @@ enum ixgbe_pfvf_api_rev {
 	ixgbe_mbox_api_10,	/* API version 1.0, linux/freebsd VF driver */
 	ixgbe_mbox_api_20,	/* API version 2.0, solaris Phase1 VF driver */
 	ixgbe_mbox_api_11,	/* API version 1.1, linux/freebsd VF driver */
+	ixgbe_mbox_api_12,	/* API version 1.2, linux/freebsd VF driver */
 	/* This value should always be last */
 	ixgbe_mbox_api_unknown,	/* indicates that API version is not known */
 };
@@ -110,6 +111,13 @@ enum ixgbe_pfvf_api_rev {
 #define IXGBE_VF_TRANS_VLAN	3	/* Indication of port vlan */
 #define IXGBE_VF_DEF_QUEUE	4	/* Default queue offset */
 
+/* mailbox API, version 1.2 VF requests */
+#define IXGBE_VF_GET_RETA	0x0a	/* VF request for RETA */
+
+/* GET_RETA request data indices within the mailbox */
+#define IXGBE_VF_RETA_SZ        1	/* Number of RETA DWs to bring */
+#define IXGBE_VF_RETA_OFFSET    2	/* Offset in RETA */
+
 /* length of permanent address message returned from PF */
 #define IXGBE_VF_PERMADDR_MSG_LEN 4
 /* word in permanent address message with the current multicast type */
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index cdb53be..cb5a4cf 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -258,6 +258,93 @@ static s32 ixgbevf_set_uc_addr_vf(struct ixgbe_hw *hw, u32 index, u8 *addr)
 	return ret_val;
 }
 
+static inline int _ixgbevf_get_reta(struct ixgbe_hw *hw, u32 *msgbuf,
+				    u32 *reta, u32 reta_offset_dw, u32 dwords)
+{
+	int err;
+
+	msgbuf[0]                    = IXGBE_VF_GET_RETA;
+	msgbuf[IXGBE_VF_RETA_SZ]     = dwords;
+	msgbuf[IXGBE_VF_RETA_OFFSET] = reta_offset_dw;
+
+	err = hw->mbx.ops.write_posted(hw, msgbuf, 3);
+
+	if (err)
+		return err;
+
+	err = hw->mbx.ops.read_posted(hw, msgbuf, 1 + dwords);
+
+	if (err)
+		return err;
+
+	msgbuf[0] &= ~IXGBE_VT_MSGTYPE_CTS;
+
+	/* If we didn't get an ACK there must have been
+	 * some sort of mailbox error so we should treat it
+	 * as such.
+	 */
+	if (msgbuf[0] != (IXGBE_VF_GET_RETA | IXGBE_VT_MSGTYPE_ACK))
+		return IXGBE_ERR_MBX;
+
+	memcpy(reta + reta_offset_dw, msgbuf + 1, 4 * dwords);
+
+	return 0;
+}
+
+/**
+ * ixgbevf_get_reta - get the RSS redirection table (RETA) contents.
+ * @hw: pointer to the HW structure
+ * @reta: buffer to fill with RETA contents.
+ *
+ * The "reta" buffer should be big enough to contain 32 registers.
+ *
+ * Returns: 0 on success.
+ *          if API doesn't support this operation - (-EPERM).
+ */
+int ixgbevf_get_reta(struct ixgbe_hw *hw, u32 *reta)
+{
+	int err;
+	u32 msgbuf[IXGBE_VFMAILBOX_SIZE];
+
+	/* Return an error if API doesn't RETA querying. */
+	if (hw->api_version != ixgbe_mbox_api_12)
+		return -EPERM;
+
+	/* x550 devices have a separate RETA for each VF: 64 bytes each.
+	 *
+	 * We'll get it in 2 steps due to mailbox size limitation - we can bring
+	 * up to 15 dwords every time. Therefore we'll bring 12 and 4 dwords.
+	 *
+	 * Older devices share a RETA table with the PF: 128 bytes.
+	 *
+	 * For them we do it in 3 steps. Therefore we'll bring it in 3 steps:
+	 * 12, 12 and 8 dwords in each step correspondingly.
+	 */
+
+	/* RETA[0..11] */
+	err = _ixgbevf_get_reta(hw, msgbuf, reta, 0, 12);
+	if (err)
+		return err;
+
+	if (hw->mac.type >= ixgbe_mac_X550_vf) {
+		/* RETA[12..15] */
+		err = _ixgbevf_get_reta(hw, msgbuf, reta, 12, 4);
+		if (err)
+			return err;
+
+	} else {
+		/* RETA[12..23] */
+		err = _ixgbevf_get_reta(hw, msgbuf, reta, 12, 12);
+		if (err)
+			return err;
+
+		/* RETA[24..31] */
+		err = _ixgbevf_get_reta(hw, msgbuf, reta, 24, 8);
+	}
+
+	return err;
+}
+
 /**
  *  ixgbevf_set_rar_vf - set device MAC address
  *  @hw: pointer to hardware structure
@@ -545,6 +632,7 @@ int ixgbevf_get_queues(struct ixgbe_hw *hw, unsigned int *num_tcs,
 	/* do nothing if API doesn't support ixgbevf_get_queues */
 	switch (hw->api_version) {
 	case ixgbe_mbox_api_11:
+	case ixgbe_mbox_api_12:
 		break;
 	default:
 		return 0;
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.h b/drivers/net/ethernet/intel/ixgbevf/vf.h
index 5b17242..73c1b33 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.h
@@ -208,5 +208,6 @@ void ixgbevf_rlpml_set_vf(struct ixgbe_hw *hw, u16 max_size);
 int ixgbevf_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(struct ixgbe_hw *hw, u32 *reta);
 #endif /* __IXGBE_VF_H__ */
 
-- 
2.1.0

^ permalink raw reply related

* Re: [PATCH net-next v3 0/5]: ixgbevf: Allow querying VFs RSS indirection table and key
From: Vlad Zolotarov @ 2015-01-05 14:47 UTC (permalink / raw)
  To: netdev; +Cc: gleb, avi, jeffrey.t.kirsher
In-Reply-To: <1420467311-6680-1-git-send-email-vladz@cloudius-systems.com>


On 01/05/15 16:15, Vlad Zolotarov wrote:
> Add the ethtool ops to VF driver to allow querying the RSS indirection table
> and RSS Random Key.
>
>   - PF driver: Add new VF-PF channel commands.
>   - VF driver: Utilize these new commands and add the corresponding
>                ethtool callbacks.

Oops - forgot to run checkpatch before sending and there were some 
issues with styling... ;)
Have just sent v4 with all styling issues fixed... ;)

>
> New in v3:
>     - Added a missing support for x550 devices.
>     - Mask the indirection table values according to PSRTYPE[n].RQPL.
>     - Minimized the number of added VF-PF commands.
>
> New in v2:
>     - Added a detailed description to patches 4 and 5.
>
> New in v1 (compared to RFC):
>     - Use "if-else" statement instead of a "switch-case" for a single option case.
>       More specifically: in cases where the newly added API version is the only one
>       allowed. We may consider using a "switch-case" back again when the list of
>       allowed API versions in these specific places grows up.
>
> Vlad Zolotarov (5):
>    ixgbe: Add a RETA query command to VF-PF channel API
>    ixgbevf: Add a RETA query code
>    ixgbe: Add GET_RSS_KEY command to VF-PF channel commands set
>    ixgbevf: Add RSS Key query code
>    ixgbevf: Add the appropriate ethtool ops to query RSS indirection
>      table and key
>
>   drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h      |  10 ++
>   drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c    |  91 +++++++++++++++
>   drivers/net/ethernet/intel/ixgbevf/ethtool.c      |  43 +++++++
>   drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |   4 +-
>   drivers/net/ethernet/intel/ixgbevf/mbx.h          |  10 ++
>   drivers/net/ethernet/intel/ixgbevf/vf.c           | 132 ++++++++++++++++++++++
>   drivers/net/ethernet/intel/ixgbevf/vf.h           |   2 +
>   7 files changed, 291 insertions(+), 1 deletion(-)
>

^ permalink raw reply

* [PATCH net-next v4 5/5] ixgbevf: Add the appropriate ethtool ops to query RSS indirection table and key
From: Vlad Zolotarov @ 2015-01-05 14:46 UTC (permalink / raw)
  To: netdev; +Cc: gleb, avi, jeffrey.t.kirsher, Vlad Zolotarov
In-Reply-To: <1420469202-1847-1-git-send-email-vladz@cloudius-systems.com>

Added get_rxfh_indir_size, get_rxfh_key_size and get_rxfh ethtool_ops callbacks
implementations.

This enables the ethtool's "-x" and "-n rx-flow-hash" options for 82599 VF devices.

Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
---
New in v4:
   - Removed not needed braces in if-statement in ixgbevf_get_rxfh_indir_size().

New in v3:
   - Added a proper support for x550 devices: return the correct redirection table size.

New in v2:
   - Added a detailed description to the patch.
---
 drivers/net/ethernet/intel/ixgbevf/ethtool.c | 42 ++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbevf/ethtool.c b/drivers/net/ethernet/intel/ixgbevf/ethtool.c
index cc0e5b7..ddf2d82 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ethtool.c
@@ -792,6 +792,45 @@ static int ixgbevf_set_coalesce(struct net_device *netdev,
 	return 0;
 }
 
+static u32 ixgbevf_get_rxfh_indir_size(struct net_device *netdev)
+{
+	struct ixgbevf_adapter *adapter = netdev_priv(netdev);
+
+	if (adapter->hw.mac.type >= ixgbe_mac_X550_vf)
+		return 64;
+	else
+		return 128;
+}
+
+static u32 ixgbevf_get_rxfh_key_size(struct net_device *netdev)
+{
+	return 40;
+}
+
+static int ixgbevf_get_rxfh(struct net_device *netdev, u32 *indir, u8 *key,
+			    u8 *hfunc)
+{
+	struct ixgbevf_adapter *adapter = netdev_priv(netdev);
+	int err;
+
+	if (hfunc)
+		*hfunc = ETH_RSS_HASH_TOP;
+
+	if (indir) {
+		err = ixgbevf_get_reta(&adapter->hw, indir);
+		if (err)
+			return err;
+	}
+
+	if (key) {
+		err = ixgbevf_get_rss_key(&adapter->hw, key);
+		if (err)
+			return err;
+	}
+
+	return 0;
+}
+
 static const struct ethtool_ops ixgbevf_ethtool_ops = {
 	.get_settings           = ixgbevf_get_settings,
 	.get_drvinfo            = ixgbevf_get_drvinfo,
@@ -809,6 +848,9 @@ static const struct ethtool_ops ixgbevf_ethtool_ops = {
 	.get_ethtool_stats      = ixgbevf_get_ethtool_stats,
 	.get_coalesce           = ixgbevf_get_coalesce,
 	.set_coalesce           = ixgbevf_set_coalesce,
+	.get_rxfh_indir_size    = ixgbevf_get_rxfh_indir_size,
+	.get_rxfh_key_size      = ixgbevf_get_rxfh_key_size,
+	.get_rxfh		= ixgbevf_get_rxfh,
 };
 
 void ixgbevf_set_ethtool_ops(struct net_device *netdev)
-- 
2.1.0

^ permalink raw reply related

* [PATCH net-next v4 4/5] ixgbevf: Add RSS Key query code
From: Vlad Zolotarov @ 2015-01-05 14:46 UTC (permalink / raw)
  To: netdev; +Cc: gleb, avi, jeffrey.t.kirsher, Vlad Zolotarov
In-Reply-To: <1420469202-1847-1-git-send-email-vladz@cloudius-systems.com>

Add the ixgbevf_get_rss_key() function that queries the PF for an RSS Random Key
using a new VF-PF channel IXGBE_VF_GET_RSS_KEY command.

Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
---
New in v2:
   - Added a more detailed patch description.

New in v1 (compared to RFC):
   - Use "if-else" statement instead of a "switch-case" for a single option case
     (in ixgbevf_get_rss_key()).
---
 drivers/net/ethernet/intel/ixgbevf/mbx.h |  2 ++
 drivers/net/ethernet/intel/ixgbevf/vf.c  | 44 ++++++++++++++++++++++++++++++++
 drivers/net/ethernet/intel/ixgbevf/vf.h  |  1 +
 3 files changed, 47 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.h b/drivers/net/ethernet/intel/ixgbevf/mbx.h
index 951a506..f79432e 100644
--- a/drivers/net/ethernet/intel/ixgbevf/mbx.h
+++ b/drivers/net/ethernet/intel/ixgbevf/mbx.h
@@ -118,6 +118,8 @@ enum ixgbe_pfvf_api_rev {
 #define IXGBE_VF_RETA_SZ        1	/* Number of RETA DWs to bring */
 #define IXGBE_VF_RETA_OFFSET    2	/* Offset in RETA */
 
+#define IXGBE_VF_GET_RSS_KEY	0x0b	/* get RSS hash key */
+
 /* length of permanent address message returned from PF */
 #define IXGBE_VF_PERMADDR_MSG_LEN 4
 /* word in permanent address message with the current multicast type */
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index cb5a4cf..f42a67d 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -292,6 +292,50 @@ static inline int _ixgbevf_get_reta(struct ixgbe_hw *hw, u32 *msgbuf,
 }
 
 /**
+ * ixgbevf_get_rss_key - get the RSS Random Key
+ * @hw: pointer to the HW structure
+ * @reta: buffer to fill with RETA contents.
+ *
+ * The "rss_key" buffer should be big enough to contain 10 registers.
+ *
+ * Returns: 0 on success.
+ *          if API doesn't support this operation - (-EPERM).
+ */
+int ixgbevf_get_rss_key(struct ixgbe_hw *hw, u8 *rss_key)
+{
+	int err;
+	u32 msgbuf[IXGBE_VFMAILBOX_SIZE];
+
+	/* Return and error if API doesn't support RSS Random Key retrieval */
+	if (hw->api_version != ixgbe_mbox_api_12)
+		return -EPERM;
+
+	msgbuf[0] = IXGBE_VF_GET_RSS_KEY;
+	err = hw->mbx.ops.write_posted(hw, msgbuf, 1);
+
+	if (err)
+		return err;
+
+	err = hw->mbx.ops.read_posted(hw, msgbuf, 11);
+
+	if (err)
+		return err;
+
+	msgbuf[0] &= ~IXGBE_VT_MSGTYPE_CTS;
+
+	/* If we didn't get an ACK there must have been
+	 * some sort of mailbox error so we should treat it
+	 * as such.
+	 */
+	if (msgbuf[0] != (IXGBE_VF_GET_RSS_KEY | IXGBE_VT_MSGTYPE_ACK))
+		return IXGBE_ERR_MBX;
+
+	memcpy(rss_key, msgbuf + 1, 40);
+
+	return 0;
+}
+
+/**
  * ixgbevf_get_reta - get the RSS redirection table (RETA) contents.
  * @hw: pointer to the HW structure
  * @reta: buffer to fill with RETA contents.
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.h b/drivers/net/ethernet/intel/ixgbevf/vf.h
index 73c1b33..54f53f2b8 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.h
@@ -209,5 +209,6 @@ int ixgbevf_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(struct ixgbe_hw *hw, u32 *reta);
+int ixgbevf_get_rss_key(struct ixgbe_hw *hw, u8 *rss_key);
 #endif /* __IXGBE_VF_H__ */
 
-- 
2.1.0

^ permalink raw reply related

* [PATCH net-next v4 3/5] ixgbe: Add GET_RSS_KEY command to VF-PF channel commands set
From: Vlad Zolotarov @ 2015-01-05 14:46 UTC (permalink / raw)
  To: netdev; +Cc: gleb, avi, jeffrey.t.kirsher, Vlad Zolotarov
In-Reply-To: <1420469202-1847-1-git-send-email-vladz@cloudius-systems.com>

For 82599 and x540 VFs and PF share the same RSS Key. Therefore we will return
the same RSS key for all VFs.

x550 on the other hand has a separate RSS Key for every pool.

Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
---
New in v3:
   - Added a support for x550 devices.

New in v1 (compared to RFC):
   - Use "if-else" statement instead of a "switch-case" for a single option case
     (in ixgbe_get_vf_rss_key()).
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h   |  2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 26 ++++++++++++++++++++++++++
 2 files changed, 28 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
index f9b5eae..3f14373 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
@@ -105,6 +105,8 @@ enum ixgbe_pfvf_api_rev {
 #define IXGBE_VF_RETA_SZ        1	/* Number of RETA DWs to bring */
 #define IXGBE_VF_RETA_OFFSET    2	/* Offset in RETA */
 
+#define IXGBE_VF_GET_RSS_KEY	0x0b	/* get RSS key */
+
 /* length of permanent address message returned from PF */
 #define IXGBE_VF_PERMADDR_MSG_LEN 4
 /* word in permanent address message with the current multicast type */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 8d6ebb3..d29cd36 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -1005,6 +1005,29 @@ static int ixgbe_get_vf_reta(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
 	return 0;
 }
 
+static int ixgbe_get_vf_rss_key(struct ixgbe_adapter *adapter,
+				u32 *msgbuf, u32 vf)
+{
+	struct ixgbe_hw *hw = &adapter->hw;
+	int i;
+	u32 *rss_key = &msgbuf[1];
+
+	/* verify the PF is supporting the correct API */
+	if (adapter->vfinfo[vf].vf_api != ixgbe_mbox_api_12)
+		return -EPERM;
+
+	/* Read the RSS KEY */
+	if (hw->mac.type >= ixgbe_mac_X550) {
+		for (i = 0; i < 10; i++)
+			rss_key[i] = IXGBE_READ_REG(hw,
+						IXGBE_PFVFRSSRK(i, vf));
+	} else
+		for (i = 0; i < 10; i++)
+			rss_key[i] = IXGBE_READ_REG(hw, IXGBE_RSSRK(i));
+
+	return 0;
+}
+
 static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
 {
 	u32 mbx_size = IXGBE_VFMAILBOX_SIZE;
@@ -1064,6 +1087,9 @@ static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
 	case IXGBE_VF_GET_RETA:
 		retval = ixgbe_get_vf_reta(adapter, msgbuf, vf);
 		break;
+	case IXGBE_VF_GET_RSS_KEY:
+		retval = ixgbe_get_vf_rss_key(adapter, msgbuf, vf);
+		break;
 	default:
 		e_err(drv, "Unhandled Msg %8.8x\n", msgbuf[0]);
 		retval = IXGBE_ERR_MBX;
-- 
2.1.0

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox