* Re: [PATCH] Disable TSO for non standard qdiscs
From: Andi Kleen @ 2008-02-01 7:46 UTC (permalink / raw)
To: Glen Turner
Cc: Andi Kleen, Waskiewicz Jr, Peter P, Patrick McHardy,
Stephen Hemminger, netdev
In-Reply-To: <1201847738.17656.5.camel@roma.44ansell.gdt.id.au>
> The problem with ethtool is that it's a non-obvious nerd knob. At
> the least the ethtool documentation should be updated to indicate that
> activating TSO effects tc accuracy.
TSO tends to be activated by default in the driver; very few people who use it
do even know that ethtool exist or what TSO is.
-Andi
^ permalink raw reply
* Re: [2.6 patch] rtnetlink.c: #if 0 no longer used functions
From: Patrick McHardy @ 2008-02-01 7:00 UTC (permalink / raw)
To: David Miller; +Cc: bunk, netdev
In-Reply-To: <20080131.171751.192428440.davem@davemloft.net>
David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Wed, 30 Jan 2008 21:04:33 +0100
>
>> Adrian Bunk wrote:
>>> This patch #if 0's the following no longer used functions:
>>> - rtattr_parse()
>>> - rtattr_strlcpy()
>>> - __rtattr_parse_nested_compat()
>>>
>> Please remove them instead.
>
> Agreed.
The rtattr_parse_nested_compat macro can also go away.
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Patrick McHardy @ 2008-02-01 6:46 UTC (permalink / raw)
To: Glen Turner; +Cc: Andi Kleen, Waskiewicz Jr, Peter P, Stephen Hemminger, netdev
In-Reply-To: <1201847738.17656.5.camel@roma.44ansell.gdt.id.au>
Glen Turner wrote:
> On Thu, 2008-01-31 at 20:34 +0100, Andi Kleen wrote:
>
>> The philosophical problem I have with this suggestion is that I expect
>> that the large majority of users will be more happy with disabled TSO
>> if they use non standard qdiscs and defaults that do not fit
>> the majority use case are bad.
>
> I wouldn't be so fast to assume that all users need an exact playout
> rate, as people seem to do fine with the 8Kbps playout steps in Cisco
> IOS. A nerd-knob which expresses user's preference in the
> accuracy/performance trade-off would be nice.
>
> The problem with ethtool is that it's a non-obvious nerd knob. At
> the least the ethtool documentation should be updated to indicate that
> activating TSO effects tc accuracy.
I agree with Andi, most user neither know nor care about TSO.
It should work properly by default and optimizations should
be explicitly configured. This is especially true if you
consider the common userbase of qdiscs - which is mostly
slow DSL lines, cablemodems etc.
^ permalink raw reply
* [PATCH] add if_addrlabel.h to sanitized headers
From: Stephen Hemminger @ 2008-02-01 6:37 UTC (permalink / raw)
Cc: netdev
In-Reply-To: <20080128.210222.07062540.yoshfuji@linux-ipv6.org>
if_addrlabel.h is needed for iproute2 usage.
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
---
include/linux/Kbuild | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index 85b2482..ce9d0fd 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -218,6 +218,7 @@ unifdef-y += i2c-dev.h
unifdef-y += icmp.h
unifdef-y += icmpv6.h
unifdef-y += if_addr.h
+unifdef-y += if_addrlabel.h
unifdef-y += if_arp.h
unifdef-y += if_bridge.h
unifdef-y += if_ec.h
--
1.5.3.8
^ permalink raw reply related
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Glen Turner @ 2008-02-01 6:35 UTC (permalink / raw)
To: Andi Kleen
Cc: Waskiewicz Jr, Peter P, Patrick McHardy, Stephen Hemminger,
netdev
In-Reply-To: <20080131193406.GH4671@one.firstfloor.org>
On Thu, 2008-01-31 at 20:34 +0100, Andi Kleen wrote:
> The philosophical problem I have with this suggestion is that I expect
> that the large majority of users will be more happy with disabled TSO
> if they use non standard qdiscs and defaults that do not fit
> the majority use case are bad.
I wouldn't be so fast to assume that all users need an exact playout
rate, as people seem to do fine with the 8Kbps playout steps in Cisco
IOS. A nerd-knob which expresses user's preference in the
accuracy/performance trade-off would be nice.
The problem with ethtool is that it's a non-obvious nerd knob. At
the least the ethtool documentation should be updated to indicate that
activating TSO effects tc accuracy.
Best wishes, Glen
[a network engineer]
^ permalink raw reply
* Re: [IPROUTE 02/02]: Add flow classifier support
From: Stephen Hemminger @ 2008-02-01 6:28 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Linux Netdev List
In-Reply-To: <47A20C63.6030806@trash.net>
applied both to git
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Bill Fink @ 2008-02-01 6:27 UTC (permalink / raw)
To: Bruce Allen
Cc: Kok, Auke, Brandeburg, Jesse, netdev, Carsten Aulbert,
Henning Fehrmann, Bruce Allen
In-Reply-To: <Pine.LNX.4.63.0801311340270.14403@trinity.phys.uwm.edu>
On Thu, 31 Jan 2008, Bruce Allen wrote:
> >> Based on the discussion in this thread, I am inclined to believe that
> >> lack of PCI-e bus bandwidth is NOT the issue. The theory is that the
> >> extra packet handling associated with TCP acknowledgements are pushing
> >> the PCI-e x1 bus past its limits. However the evidence seems to show
> >> otherwise:
> >>
> >> (1) Bill Fink has reported the same problem on a NIC with a 133 MHz
> >> 64-bit PCI connection. That connection can transfer data at 8Gb/s.
> >
> > That was even a PCI-X connection, which is known to have extremely good latency
> > numbers, IIRC better than PCI-e? (?) which could account for a lot of the
> > latency-induced lower performance...
> >
> > also, 82573's are _not_ a serverpart and were not designed for this
> > usage. 82546's are and that really does make a difference.
>
> I'm confused. It DOESN'T make a difference! Using 'server grade' 82546's
> on a PCI-X bus, Bill Fink reports the SAME loss of throughput with TCP
> full duplex that we see on a 'consumer grade' 82573 attached to a PCI-e x1
> bus.
>
> Just like us, when Bill goes from TCP to UDP, he gets wire speed back.
Good. I thought it was just me who was confused by Auke's reply. :-)
Yes, I get the same type of reduced TCP performance behavior on a
bidirectional test that Bruce has seen, even though I'm using the
better 82546 GigE NIC on a faster 64-bit/133-MHz PCI-X bus. I also
don't think bus bandwidth is an issue, but I am curious if there
are any known papers on typical PCI-X/PCI-E bus overhead on network
transfers, either bulk data transfers with large packets or more
transaction or video based applications using smaller packets.
I started musing if once one side's transmitter got the upper hand,
it might somehow defer the processing of received packets, causing
the resultant ACKs to be delayed and thus further slowing down the
other end's transmitter. I began to wonder if the txqueuelen could
have an affect on the TCP performance behavior. I normally have
the txqueuelen set to 10000 for 10-GigE testing, so decided to run
a test with txqueuelen set to 200 (actually settled on this value
through some experimentation). Here is a typical result:
[bill@chance4 ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 & nuttcp -f-beta -Irx -r -w2m 192.168.6.79
tx: 1120.6345 MB / 10.07 sec = 933.4042 Mbps 12 %TX 9 %RX 0 retrans
rx: 1104.3081 MB / 10.09 sec = 917.7365 Mbps 12 %TX 11 %RX 0 retrans
This is significantly better, but there was more variability in the
results. The above was with TSO enabled. I also then ran a test
with TSO disabled, with the following typical result:
[bill@chance4 ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 & nuttcp -f-beta -Irx -r -w2m 192.168.6.79
tx: 1119.4749 MB / 10.05 sec = 934.2922 Mbps 13 %TX 9 %RX 0 retrans
rx: 1131.7334 MB / 10.05 sec = 944.8437 Mbps 15 %TX 12 %RX 0 retrans
This was a little better yet and getting closer to expected results.
Jesse Brandeburg mentioned in another post that there were known
performance issues with the version of the e1000 driver I'm using.
I recognized that the kernel/driver versions I was using were rather
old, but it was what I had available to do a quick test with. Those
particular systems are in a remote location so I have to be careful
with messing with their network drivers. I do have some other test
systems at work that I might be able to try with newer kernels
and/or drivers or maybe even with other vendor's GigE NICs, but
I won't be back to work until early next week sometime.
-Bill
^ permalink raw reply
* Re: [PATCH] vlan tag match
From: Stephen Hemminger @ 2008-02-01 5:50 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David Miller, netdev
In-Reply-To: <47A2AF6A.1060200@trash.net>
On Fri, 01 Feb 2008 06:34:34 +0100
Patrick McHardy <kaber@trash.net> wrote:
> Stephen Hemminger wrote:
> > Provide a way to use tc filters on vlan tag even if tag is buried in
> > skb due to hardware acceleration.
>
> Looks reasonable. Would you like to add the same feature to the
> flow classifier?
>
Yes, that would be good.
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: [PATCH] vlan tag match
From: Patrick McHardy @ 2008-02-01 5:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20080131210732.25f42884@extreme>
Stephen Hemminger wrote:
> Provide a way to use tc filters on vlan tag even if tag is buried in
> skb due to hardware acceleration.
Looks reasonable. Would you like to add the same feature to the
flow classifier?
^ permalink raw reply
* [PATCH] vlan tag match
From: Stephen Hemminger @ 2008-02-01 5:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Patrick McHardy
In-Reply-To: <20080131.194644.03127203.davem@davemloft.net>
Provide a way to use tc filters on vlan tag even if tag is buried in
skb due to hardware acceleration.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
include/linux/pkt_cls.h | 3 ++-
include/linux/tc_ematch/tc_em_meta.h | 1 +
net/sched/em_meta.c | 17 +++++++++++++++++
3 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index 1c1dba9..40fac8c 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -459,7 +459,8 @@ enum
#define TCF_EM_U32 3
#define TCF_EM_META 4
#define TCF_EM_TEXT 5
-#define TCF_EM_MAX 5
+#define TCF_EM_VLAN 6
+#define TCF_EM_MAX 6
enum
{
diff --git a/include/linux/tc_ematch/tc_em_meta.h b/include/linux/tc_ematch/tc_em_meta.h
index e21937c..c50d2ba 100644
--- a/include/linux/tc_ematch/tc_em_meta.h
+++ b/include/linux/tc_ematch/tc_em_meta.h
@@ -81,6 +81,7 @@ enum
TCF_META_ID_SK_SNDTIMEO,
TCF_META_ID_SK_SENDMSG_OFF,
TCF_META_ID_SK_WRITE_PENDING,
+ TCF_META_ID_VLAN_TAG,
__TCF_META_ID_MAX
};
#define TCF_META_ID_MAX (__TCF_META_ID_MAX - 1)
diff --git a/net/sched/em_meta.c b/net/sched/em_meta.c
index a1e5619..9c2ec19 100644
--- a/net/sched/em_meta.c
+++ b/net/sched/em_meta.c
@@ -65,6 +65,7 @@
#include <linux/string.h>
#include <linux/skbuff.h>
#include <linux/random.h>
+#include <linux/if_vlan.h>
#include <linux/tc_ematch/tc_em_meta.h>
#include <net/dst.h>
#include <net/route.h>
@@ -170,6 +171,21 @@ META_COLLECTOR(var_dev)
}
/**************************************************************************
+ * vlan tag
+ **************************************************************************/
+
+META_COLLECTOR(int_vlan_tag)
+{
+ unsigned short tag;
+ if (vlan_get_tag(skb, &tag) < 0)
+ *err = -1;
+ else
+ dst->value = tag;
+}
+
+
+
+/**************************************************************************
* skb attributes
**************************************************************************/
@@ -520,6 +536,7 @@ static struct meta_ops __meta_ops[TCF_META_TYPE_MAX+1][TCF_META_ID_MAX+1] = {
[META_ID(SK_SNDTIMEO)] = META_FUNC(int_sk_sndtimeo),
[META_ID(SK_SENDMSG_OFF)] = META_FUNC(int_sk_sendmsg_off),
[META_ID(SK_WRITE_PENDING)] = META_FUNC(int_sk_write_pend),
+ [META_ID(VLAN_TAG)] = META_FUNC(int_vlan_tag),
}
};
--
1.5.3.8
^ permalink raw reply related
* Re: [PATCH 0/5] ehea checkpatch fixups
From: Doug Maxey @ 2008-02-01 4:35 UTC (permalink / raw)
To: Nathan Lynch
Cc: Doug Maxey, Jeff Garzik, Linux PowerPC List, netdev,
Paul Mackerras, Jan-Bernd Themann
In-Reply-To: <20080201030542.GX14201@localdomain>
On Thu, 31 Jan 2008 21:05:42 CST, Nathan Lynch wrote:
> Doug Maxey wrote:
> >
> > A small set of fixups for checkpatch.
> >
> > Based on upstream pull from a few hours ago.
>
> Er, ehea doesn't even build right now[1], maybe that could get fixed
> first? :-)
>
> [1] http://lkml.org/lkml/2008/1/28/337
For sure these won't break it any worse. ;) Think of these more as a
janitorial thing vs. structural.
Doesn't gregkh's patch work? At least for the interim?
Jan-Bernd,
What tools are looking in sysfs? distro scripts? I don't see any link
between ethtool and the driver (other than the driver internal bits).
Am I missing something obvious?
++doug
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Andi Kleen @ 2008-02-01 5:01 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Andi Kleen, Waskiewicz Jr, Peter P, Patrick McHardy,
Stephen Hemminger, netdev
In-Reply-To: <47A230A8.7080100@gmail.com>
On Thu, Jan 31, 2008 at 09:33:44PM +0100, Jarek Poplawski wrote:
> Andi Kleen wrote, On 01/31/2008 08:34 PM:
>
> >> TSO by nature is bursty. But disabling TSO without the option of having
> >> it on or off to me seems to aggressive. If someone is using a qdisc
> >> that TSO is interfering with the effectiveness of the traffic shaping,
> >> then they should turn off TSO via ethtool on the target device. Some
> >
> > The philosophical problem I have with this suggestion is that I expect
> > that the large majority of users will be more happy with disabled TSO
> > if they use non standard qdiscs and defaults that do not fit
> > the majority use case are bad.
>
>
> If you mean the large majority of the large minority of users, who use
> non standard qdiscs - I agree - this is really the philosophical problem!
[....] Sorry if you had a point in this email I missed it.
-Andi
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Patrick McHardy @ 2008-02-01 4:26 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P
Cc: Arnaldo Carvalho de Melo, Andi Kleen, Stephen Hemminger, netdev
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC3290133D2A0@orsmsx414.amr.corp.intel.com>
Waskiewicz Jr, Peter P wrote:
>> Well, it could be just that when using such qdiscs TSO would be
>> disabled, but the user could override this by using ethtool after
>> loading the qdiscs.
>
> I still disagree with this. The qdisc should not cause anything to happen to feature flags on the device. It's the scheduling layer and really shouldn't care about what features the device supports or not. If someone has an issue with a feature hurting performance or causing odd behavior when using a qdisc, then they should disable the feature on the device using the appropriate tools provided. If it's the qdisc causing issues, then either the qdisc needs to be fixed, or it should be documented what features are recommended to be on and off with the qdisc. I don't agree that the scheduling layer should affect features on an underlying device.
Andi's patch made the TSO capable flag a property of the
qdisc (not the ops), so it could still be explicitly
configured by the user.
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Andi Kleen @ 2008-02-01 4:36 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Waskiewicz Jr, Peter P, Andi Kleen,
Patrick McHardy, Stephen
In-Reply-To: <20080131231045.GA5543@ghostprotocols.net>
> Well, it could be just that when using such qdiscs TSO would be
> disabled, but the user could override this by using ethtool after
> loading the qdiscs.
If anything TC, not ethtool. Do you have an useful scenario where
GSO makes sense with TBF et.al.?
-Andi
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Andi Kleen @ 2008-02-01 4:35 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P
Cc: Arnaldo Carvalho de Melo, Andi Kleen, Patrick McHardy,
Stephen Hemminger, netdev
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC3290133D2A0@orsmsx414.amr.corp.intel.com>
On Thu, Jan 31, 2008 at 03:42:54PM -0800, Waskiewicz Jr, Peter P wrote:
> > Well, it could be just that when using such qdiscs TSO would be
> > disabled, but the user could override this by using ethtool after
> > loading the qdiscs.
>
> I still disagree with this. The qdisc should not cause anything to happen to feature flags on the device. It's the scheduling layer and really shouldn't care about what features the device supports or not. If someone has an issue with a feature hurting performance or causing odd behavior when using a qdisc, then they should disable the feature on the device using the appropriate tools provided. If it's the qdisc causing issues, then either the qdisc needs to be fixed, or it should be documented what features are recommended to be on and off with the qdisc. I don't agree that the scheduling layer should affect features on an underlying device.
You seem to only look at this from a high level theoretical standpoint.
But more down to earth: do you have a useful scenario where it makes
sense to do shaping or another qdisc on GSO packets? My take is that
when you decide to do any packet scheduling you really want to do
it on wire packets, not some internal stack implementation implementation
detail units.
-Andi
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Andi Kleen @ 2008-02-01 4:31 UTC (permalink / raw)
To: Rick Jones; +Cc: Andi Kleen, netdev, davem
In-Reply-To: <47A21E1A.6000006@hp.com>
On Thu, Jan 31, 2008 at 11:14:34AM -0800, Rick Jones wrote:
> Sounds like the functionality needs to be in the DSL bridge :) (or the
> "router" in the same case) Particularly since it might be getting used
> by more than one host on the GbE switch.
Possible, but it is not usually in the real world. Setups like
WonderShaper which do this on the host side are pretty common.
> then the qdisc could/should place a cap on the size of a 'TSO' based on
> the bitrate (and perhaps input as to how much time any one "burst" of
> data should be allowed to consume on the network) and pass that up the
> stack? right now you seem to be proposing what is effectively a cap of
> 1 MSS.
Hmm, that would probably be possible for TBF, but I'm not sure this can be
really done in a useful way for the more complicated qdiscs. Especially
since they would likely need to turn on/off GSO regularly when dynamic
circumstances change and there is not really a good way to affect a socket
after it was created.
-Andi
^ permalink raw reply
* "no new features"...
From: David Miller @ 2008-02-01 3:46 UTC (permalink / raw)
To: netdev
I've just sent a pull request to Linus for net-2.6 and that should
effectively be my final feature merge to him.
Outside of the 6-patch thing Arnaldo is respinning I am calling for no
new stuff to go in at this time. Only bug fixes.
We've merged a lot of stuff already (on the order of 1800 patches in
total). So we should draw the line in the sand so that we can have
some hope to fix the almost guarenteed bugs.
Many folks, including Linus, are flying home this weekend.
So my basic plan is to open up a net-2.6.26 tree about a week and a
half from now.
Please set your feature work aside for the moment and find a fun
bug to fix instead. :-)
Thanks!
^ permalink raw reply
* Re: [PATCH 0/5] ehea checkpatch fixups
From: Nathan Lynch @ 2008-02-01 3:05 UTC (permalink / raw)
To: Doug Maxey
Cc: Jeff Garzik, Linux PowerPC List, netdev, Paul Mackerras,
Jan-Bernd Themann
In-Reply-To: <1201832451-23634-1-git-send-email-dwm@austin.ibm.com>
Doug Maxey wrote:
>
> A small set of fixups for checkpatch.
>
> Based on upstream pull from a few hours ago.
Er, ehea doesn't even build right now[1], maybe that could get fixed
first? :-)
[1] http://lkml.org/lkml/2008/1/28/337
^ permalink raw reply
* Re: [PATCH retry] bluetooth : add conn add/del workqueues to avoid connection fail
From: Dave Young @ 2008-02-01 2:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, marcel, linux-kernel, bluez-devel, jens.axboe
In-Reply-To: <20080131.183358.229943667.davem@davemloft.net>
On Feb 1, 2008 10:33 AM, David Miller <davem@davemloft.net> wrote:
> From: Dave Young <hidave.darkstar@gmail.com>
> Date: Fri, 1 Feb 2008 09:24:41 +0800
>
>
> > On Thu, Jan 31, 2008 at 02:09:30PM +0100, Jens Axboe wrote:
> > > On Wed, Jan 30 2008, Dave Young wrote:
> > > >
> > > > The bluetooth hci_conn sysfs add/del executed in the default workqueue.
> > > > If the del_conn is executed after the new add_conn with same target,
> > > > add_conn will failed with warning of "same kobject name".
> > > >
> > > > Here add btaddconn & btdelconn workqueues,
> > > > flush the btdelconn workqueue in the add_conn function to avoid the issue.
> > > >
> > > > Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
> > > >
> > > > ---
> > > > diff -upr a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
> > > > --- a/net/bluetooth/hci_sysfs.c 2008-01-30 10:14:27.000000000 +0800
> > > > +++ b/net/bluetooth/hci_sysfs.c 2008-01-30 10:14:14.000000000 +0800
> > > > @@ -12,6 +12,8 @@
> > > > #undef BT_DBG
> > > > #define BT_DBG(D...)
> > > > #endif
> > > > +static struct workqueue_struct *btaddconn;
> > > > +static struct workqueue_struct *btdelconn;
> > > >
> > > > static inline char *typetostr(int type)
> > > > {
> > > > @@ -279,6 +281,7 @@ static void add_conn(struct work_struct
> > > > struct hci_conn *conn = container_of(work, struct hci_conn, work);
> > > > int i;
> > > >
> > > > + flush_workqueue(btdelconn);
> > > > if (device_add(&conn->dev) < 0) {
> > > > BT_ERR("Failed to register connection device");
> > > > return;
> > > > @@ -313,6 +316,7 @@ void hci_conn_add_sysfs(struct hci_conn
> > > >
> > > > INIT_WORK(&conn->work, add_conn);
> > > >
> > > > + queue_work(btaddconn, &conn->work);
> > > > schedule_work(&conn->work);
> > > > }
> > >
> > > So you queue &conn->work on both btaddconn and keventd_wq?
> >
> > My fault. Thanks for pointing out.
> >
> > new patch as following (some fixes according to marcel's style as well)
>
> Your original patch was already in the tree, so I just checked
> in the relative changes.
>
> Please don't me do this next time :-)
David, sorry for it. Should be more careful.
Thanks :)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: [PATCH 0/6] preparations to enable netdevice notifiers inside a namespace (resend)
From: David Miller @ 2008-02-01 2:50 UTC (permalink / raw)
To: den; +Cc: netdev, devel, containers
In-Reply-To: <47A1B835.7050600@sw.ru>
From: "Denis V. Lunev" <den@sw.ru>
Date: Thu, 31 Jan 2008 14:59:49 +0300
> Here are some preparations and cleanups to enable network device/inet
> address notifiers inside a namespace.
>
> This set of patches has been originally sent last Friday. One cleanup
> patch from the original series is dropped as wrong, thanks to Daniel
> Lezcano.
All applied, thanks.
^ permalink raw reply
* Re: [PATCHES 0/6]: Move hashinfo to sk_prot and struct reorgs
From: David Miller @ 2008-02-01 2:40 UTC (permalink / raw)
To: acme; +Cc: netdev, dccp
In-Reply-To: <1201804304-28777-1-git-send-email-acme@redhat.com>
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Thu, 31 Jan 2008 16:31:38 -0200
> Hi David,
>
> Please consider pulling from:
>
> master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6
I've had to rebase my tree a few times and there are
conflicts in this merge as well.
Sit tight for a day or so, I'd like to merge the current
tree to Linus and then maybe look at a few more things.
^ permalink raw reply
* Re: [NET_SCHED 00/04]: External SFQ classifiers/flow classifier
From: David Miller @ 2008-02-01 2:37 UTC (permalink / raw)
To: kaber; +Cc: netdev, shemminger
In-Reply-To: <20080131175758.25151.20370.sendpatchset@localhost.localdomain>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 31 Jan 2008 18:58:02 +0100 (MET)
> These patches add support for external classifiers to SFQ and add a
> new "flow" classifier, which can do hashing based on user-specified
> keys or deterministic mapping of keys to classes. Additionally there
> is a patch to make the SFQ queues visisble as classes to verify that
> the hash is indeed doing something useful and a patch to consifiy
> struct tcf_ext_map, which I had queued in the same tree.
>
> Please apply, thanks.
Applied, thanks Patrick.
^ permalink raw reply
* Re: [PATCH retry] bluetooth : add conn add/del workqueues to avoid connection fail
From: David Miller @ 2008-02-01 2:33 UTC (permalink / raw)
To: hidave.darkstar; +Cc: netdev, marcel, linux-kernel, bluez-devel, jens.axboe
In-Reply-To: <20080201012441.GA2924@darkstar.te-china.tietoenator.com>
From: Dave Young <hidave.darkstar@gmail.com>
Date: Fri, 1 Feb 2008 09:24:41 +0800
> On Thu, Jan 31, 2008 at 02:09:30PM +0100, Jens Axboe wrote:
> > On Wed, Jan 30 2008, Dave Young wrote:
> > >
> > > The bluetooth hci_conn sysfs add/del executed in the default workqueue.
> > > If the del_conn is executed after the new add_conn with same target,
> > > add_conn will failed with warning of "same kobject name".
> > >
> > > Here add btaddconn & btdelconn workqueues,
> > > flush the btdelconn workqueue in the add_conn function to avoid the issue.
> > >
> > > Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
> > >
> > > ---
> > > diff -upr a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
> > > --- a/net/bluetooth/hci_sysfs.c 2008-01-30 10:14:27.000000000 +0800
> > > +++ b/net/bluetooth/hci_sysfs.c 2008-01-30 10:14:14.000000000 +0800
> > > @@ -12,6 +12,8 @@
> > > #undef BT_DBG
> > > #define BT_DBG(D...)
> > > #endif
> > > +static struct workqueue_struct *btaddconn;
> > > +static struct workqueue_struct *btdelconn;
> > >
> > > static inline char *typetostr(int type)
> > > {
> > > @@ -279,6 +281,7 @@ static void add_conn(struct work_struct
> > > struct hci_conn *conn = container_of(work, struct hci_conn, work);
> > > int i;
> > >
> > > + flush_workqueue(btdelconn);
> > > if (device_add(&conn->dev) < 0) {
> > > BT_ERR("Failed to register connection device");
> > > return;
> > > @@ -313,6 +316,7 @@ void hci_conn_add_sysfs(struct hci_conn
> > >
> > > INIT_WORK(&conn->work, add_conn);
> > >
> > > + queue_work(btaddconn, &conn->work);
> > > schedule_work(&conn->work);
> > > }
> >
> > So you queue &conn->work on both btaddconn and keventd_wq?
>
> My fault. Thanks for pointing out.
>
> new patch as following (some fixes according to marcel's style as well)
Your original patch was already in the tree, so I just checked
in the relative changes.
Please don't me do this next time :-)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* [PATCH 5/5] ehea: fix qmr checkpatch complaints
From: Doug Maxey @ 2008-02-01 2:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux PowerPC List, netdev, Paul Mackerras, Jan-Bernd Themann
In-Reply-To: <1201832451-23634-1-git-send-email-dwm@austin.ibm.com>
Cc: Jan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: Doug Maxey <dwm@austin.ibm.com>
---
drivers/net/ehea/ehea_qmr.c | 32 ++++++++++++++++----------------
drivers/net/ehea/ehea_qmr.h | 16 ++++++++--------
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ehea/ehea_qmr.c b/drivers/net/ehea/ehea_qmr.c
index 83b7643..d522e90 100644
--- a/drivers/net/ehea/ehea_qmr.c
+++ b/drivers/net/ehea/ehea_qmr.c
@@ -33,8 +33,6 @@
struct ehea_busmap ehea_bmap = { 0, 0, NULL };
-extern u64 ehea_driver_flags;
-extern struct work_struct ehea_rereg_mr_task;
static void *hw_qpageit_get_inc(struct hw_queue *queue)
@@ -65,7 +63,7 @@ static int hw_queue_ctor(struct hw_queue *queue, const u32 nr_of_pages,
}
queue->queue_length = nr_of_pages * pagesize;
- queue->queue_pages = kmalloc(nr_of_pages * sizeof(void*), GFP_KERNEL);
+ queue->queue_pages = kmalloc(nr_of_pages * sizeof(void *), GFP_KERNEL);
if (!queue->queue_pages) {
ehea_error("no mem for queue_pages");
return -ENOMEM;
@@ -78,11 +76,11 @@ static int hw_queue_ctor(struct hw_queue *queue, const u32 nr_of_pages,
*/
i = 0;
while (i < nr_of_pages) {
- u8 *kpage = (u8*)get_zeroed_page(GFP_KERNEL);
+ u8 *kpage = (u8 *)get_zeroed_page(GFP_KERNEL);
if (!kpage)
goto out_nomem;
for (k = 0; k < pages_per_kpage && i < nr_of_pages; k++) {
- (queue->queue_pages)[i] = (struct ehea_page*)kpage;
+ (queue->queue_pages)[i] = (struct ehea_page *)kpage;
kpage += pagesize;
i++;
}
@@ -235,8 +233,8 @@ int ehea_destroy_cq(struct ehea_cq *cq)
return 0;
hcp_epas_dtor(&cq->epas);
-
- if ((hret = ehea_destroy_cq_res(cq, NORMAL_FREE)) == H_R_STATE) {
+ hret = ehea_destroy_cq_res(cq, NORMAL_FREE);
+ if (hret == H_R_STATE) {
ehea_error_data(cq->adapter, cq->fw_handle);
hret = ehea_destroy_cq_res(cq, FORCE_FREE);
}
@@ -301,13 +299,13 @@ struct ehea_eq *ehea_create_eq(struct ehea_adapter *adapter,
if (i == (eq->attr.nr_pages - 1)) {
/* last page */
vpage = hw_qpageit_get_inc(&eq->hw_queue);
- if ((hret != H_SUCCESS) || (vpage)) {
+ if ((hret != H_SUCCESS) || (vpage))
goto out_kill_hwq;
- }
+
} else {
- if ((hret != H_PAGE_REGISTERED) || (!vpage)) {
+ if ((hret != H_PAGE_REGISTERED) || (!vpage))
goto out_kill_hwq;
- }
+
}
}
@@ -331,7 +329,7 @@ struct ehea_eqe *ehea_poll_eq(struct ehea_eq *eq)
unsigned long flags;
spin_lock_irqsave(&eq->spinlock, flags);
- eqe = (struct ehea_eqe*)hw_eqit_eq_get_inc_valid(&eq->hw_queue);
+ eqe = (struct ehea_eqe *)hw_eqit_eq_get_inc_valid(&eq->hw_queue);
spin_unlock_irqrestore(&eq->spinlock, flags);
return eqe;
@@ -364,7 +362,8 @@ int ehea_destroy_eq(struct ehea_eq *eq)
hcp_epas_dtor(&eq->epas);
- if ((hret = ehea_destroy_eq_res(eq, NORMAL_FREE)) == H_R_STATE) {
+ hret = ehea_destroy_eq_res(eq, NORMAL_FREE);
+ if (hret == H_R_STATE) {
ehea_error_data(eq->adapter, eq->fw_handle);
hret = ehea_destroy_eq_res(eq, FORCE_FREE);
}
@@ -546,7 +545,8 @@ int ehea_destroy_qp(struct ehea_qp *qp)
hcp_epas_dtor(&qp->epas);
- if ((hret = ehea_destroy_qp_res(qp, NORMAL_FREE)) == H_R_STATE) {
+ hret = ehea_destroy_qp_res(qp, NORMAL_FREE);
+ if (hret == H_R_STATE) {
ehea_error_data(qp->adapter, qp->fw_handle);
hret = ehea_destroy_qp_res(qp, FORCE_FREE);
}
@@ -559,7 +559,7 @@ int ehea_destroy_qp(struct ehea_qp *qp)
return 0;
}
-int ehea_create_busmap( void )
+int ehea_create_busmap(void)
{
u64 vaddr = EHEA_BUSMAP_START;
unsigned long high_section_index = 0;
@@ -595,7 +595,7 @@ int ehea_create_busmap( void )
return 0;
}
-void ehea_destroy_busmap( void )
+void ehea_destroy_busmap(void)
{
vfree(ehea_bmap.vaddr);
}
diff --git a/drivers/net/ehea/ehea_qmr.h b/drivers/net/ehea/ehea_qmr.h
index bc62d38..0bb6f92 100644
--- a/drivers/net/ehea/ehea_qmr.h
+++ b/drivers/net/ehea/ehea_qmr.h
@@ -41,8 +41,8 @@
#define EHEA_SECTSIZE (1UL << 24)
#define EHEA_PAGES_PER_SECTION (EHEA_SECTSIZE >> EHEA_PAGESHIFT)
-#if (1UL << SECTION_SIZE_BITS) < EHEA_SECTSIZE
-#error eHEA module can't work if kernel sectionsize < ehea sectionsize
+#if ((1UL << SECTION_SIZE_BITS) < EHEA_SECTSIZE)
+#error eHEA module cannot work if kernel sectionsize < ehea sectionsize
#endif
/* Some abbreviations used here:
@@ -188,8 +188,8 @@ struct ehea_eqe {
u64 entry;
};
-#define ERROR_DATA_LENGTH EHEA_BMASK_IBM(52,63)
-#define ERROR_DATA_TYPE EHEA_BMASK_IBM(0,7)
+#define ERROR_DATA_LENGTH EHEA_BMASK_IBM(52, 63)
+#define ERROR_DATA_TYPE EHEA_BMASK_IBM(0, 7)
static inline void *hw_qeit_calc(struct hw_queue *queue, u64 q_offset)
{
@@ -279,7 +279,7 @@ static inline void *hw_qeit_eq_get_inc(struct hw_queue *queue)
static inline void *hw_eqit_eq_get_inc_valid(struct hw_queue *queue)
{
void *retvalue = hw_qeit_get(queue);
- u32 qe = *(u8*)retvalue;
+ u32 qe = *(u8 *)retvalue;
if ((qe >> 7) == (queue->toggle_state & 1))
hw_qeit_eq_get_inc(queue);
else
@@ -364,7 +364,7 @@ struct ehea_cq *ehea_create_cq(struct ehea_adapter *adapter, int cqe,
int ehea_destroy_cq(struct ehea_cq *cq);
-struct ehea_qp *ehea_create_qp(struct ehea_adapter * adapter, u32 pd,
+struct ehea_qp *ehea_create_qp(struct ehea_adapter *adapter, u32 pd,
struct ehea_qp_init_attr *init_attr);
int ehea_destroy_qp(struct ehea_qp *qp);
@@ -378,8 +378,8 @@ int ehea_rem_mr(struct ehea_mr *mr);
void ehea_error_data(struct ehea_adapter *adapter, u64 res_handle);
-int ehea_create_busmap( void );
-void ehea_destroy_busmap( void );
+int ehea_create_busmap(void);
+void ehea_destroy_busmap(void);
u64 ehea_map_vaddr(void *caddr);
#endif /* __EHEA_QMR_H__ */
--
1.5.3.8
^ permalink raw reply related
* [PATCH 4/5] ehea: fix phyp checkpatch complaints
From: Doug Maxey @ 2008-02-01 2:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux PowerPC List, netdev, Paul Mackerras, Jan-Bernd Themann
In-Reply-To: <1201832451-23634-1-git-send-email-dwm@austin.ibm.com>
Cc: Jan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: Doug Maxey <dwm@austin.ibm.com>
---
drivers/net/ehea/ehea_phyp.c | 158 +++++++++++++++++++++---------------------
drivers/net/ehea/ehea_phyp.h | 22 +++---
2 files changed, 90 insertions(+), 90 deletions(-)
diff --git a/drivers/net/ehea/ehea_phyp.c b/drivers/net/ehea/ehea_phyp.c
index 95c4a7f..156eb63 100644
--- a/drivers/net/ehea/ehea_phyp.c
+++ b/drivers/net/ehea/ehea_phyp.c
@@ -6,9 +6,9 @@
* (C) Copyright IBM Corp. 2006
*
* Authors:
- * Christoph Raisch <raisch@de.ibm.com>
- * Jan-Bernd Themann <themann@de.ibm.com>
- * Thomas Klein <tklein@de.ibm.com>
+ * Christoph Raisch <raisch@de.ibm.com>
+ * Jan-Bernd Themann <themann@de.ibm.com>
+ * Thomas Klein <tklein@de.ibm.com>
*
*
* This program is free software; you can redistribute it and/or modify
@@ -38,11 +38,11 @@ static inline u16 get_order_of_qentries(u16 queue_entries)
}
/* Defines for H_CALL H_ALLOC_RESOURCE */
-#define H_ALL_RES_TYPE_QP 1
-#define H_ALL_RES_TYPE_CQ 2
-#define H_ALL_RES_TYPE_EQ 3
-#define H_ALL_RES_TYPE_MR 5
-#define H_ALL_RES_TYPE_MW 6
+#define H_ALL_RES_TYPE_QP 1
+#define H_ALL_RES_TYPE_CQ 2
+#define H_ALL_RES_TYPE_EQ 3
+#define H_ALL_RES_TYPE_MR 5
+#define H_ALL_RES_TYPE_MW 6
static long ehea_plpar_hcall_norets(unsigned long opcode,
unsigned long arg1,
@@ -137,77 +137,77 @@ u64 ehea_h_query_ehea_qp(const u64 adapter_handle, const u8 qp_category,
const u64 qp_handle, const u64 sel_mask, void *cb_addr)
{
return ehea_plpar_hcall_norets(H_QUERY_HEA_QP,
- adapter_handle, /* R4 */
- qp_category, /* R5 */
- qp_handle, /* R6 */
- sel_mask, /* R7 */
+ adapter_handle, /* R4 */
+ qp_category, /* R5 */
+ qp_handle, /* R6 */
+ sel_mask, /* R7 */
virt_to_abs(cb_addr), /* R8 */
0, 0);
}
/* input param R5 */
-#define H_ALL_RES_QP_EQPO EHEA_BMASK_IBM(9, 11)
-#define H_ALL_RES_QP_QPP EHEA_BMASK_IBM(12, 12)
-#define H_ALL_RES_QP_RQR EHEA_BMASK_IBM(13, 15)
-#define H_ALL_RES_QP_EQEG EHEA_BMASK_IBM(16, 16)
-#define H_ALL_RES_QP_LL_QP EHEA_BMASK_IBM(17, 17)
-#define H_ALL_RES_QP_DMA128 EHEA_BMASK_IBM(19, 19)
-#define H_ALL_RES_QP_HSM EHEA_BMASK_IBM(20, 21)
-#define H_ALL_RES_QP_SIGT EHEA_BMASK_IBM(22, 23)
-#define H_ALL_RES_QP_TENURE EHEA_BMASK_IBM(48, 55)
-#define H_ALL_RES_QP_RES_TYP EHEA_BMASK_IBM(56, 63)
+#define H_ALL_RES_QP_EQPO EHEA_BMASK_IBM(9, 11)
+#define H_ALL_RES_QP_QPP EHEA_BMASK_IBM(12, 12)
+#define H_ALL_RES_QP_RQR EHEA_BMASK_IBM(13, 15)
+#define H_ALL_RES_QP_EQEG EHEA_BMASK_IBM(16, 16)
+#define H_ALL_RES_QP_LL_QP EHEA_BMASK_IBM(17, 17)
+#define H_ALL_RES_QP_DMA128 EHEA_BMASK_IBM(19, 19)
+#define H_ALL_RES_QP_HSM EHEA_BMASK_IBM(20, 21)
+#define H_ALL_RES_QP_SIGT EHEA_BMASK_IBM(22, 23)
+#define H_ALL_RES_QP_TENURE EHEA_BMASK_IBM(48, 55)
+#define H_ALL_RES_QP_RES_TYP EHEA_BMASK_IBM(56, 63)
/* input param R9 */
-#define H_ALL_RES_QP_TOKEN EHEA_BMASK_IBM(0, 31)
-#define H_ALL_RES_QP_PD EHEA_BMASK_IBM(32,63)
+#define H_ALL_RES_QP_TOKEN EHEA_BMASK_IBM(0, 31)
+#define H_ALL_RES_QP_PD EHEA_BMASK_IBM(32, 63)
/* input param R10 */
-#define H_ALL_RES_QP_MAX_SWQE EHEA_BMASK_IBM(4, 7)
-#define H_ALL_RES_QP_MAX_R1WQE EHEA_BMASK_IBM(12, 15)
-#define H_ALL_RES_QP_MAX_R2WQE EHEA_BMASK_IBM(20, 23)
-#define H_ALL_RES_QP_MAX_R3WQE EHEA_BMASK_IBM(28, 31)
+#define H_ALL_RES_QP_MAX_SWQE EHEA_BMASK_IBM(4, 7)
+#define H_ALL_RES_QP_MAX_R1WQE EHEA_BMASK_IBM(12, 15)
+#define H_ALL_RES_QP_MAX_R2WQE EHEA_BMASK_IBM(20, 23)
+#define H_ALL_RES_QP_MAX_R3WQE EHEA_BMASK_IBM(28, 31)
/* Max Send Scatter Gather Elements */
-#define H_ALL_RES_QP_MAX_SSGE EHEA_BMASK_IBM(37, 39)
-#define H_ALL_RES_QP_MAX_R1SGE EHEA_BMASK_IBM(45, 47)
+#define H_ALL_RES_QP_MAX_SSGE EHEA_BMASK_IBM(37, 39)
+#define H_ALL_RES_QP_MAX_R1SGE EHEA_BMASK_IBM(45, 47)
/* Max Receive SG Elements RQ1 */
-#define H_ALL_RES_QP_MAX_R2SGE EHEA_BMASK_IBM(53, 55)
-#define H_ALL_RES_QP_MAX_R3SGE EHEA_BMASK_IBM(61, 63)
+#define H_ALL_RES_QP_MAX_R2SGE EHEA_BMASK_IBM(53, 55)
+#define H_ALL_RES_QP_MAX_R3SGE EHEA_BMASK_IBM(61, 63)
/* input param R11 */
-#define H_ALL_RES_QP_SWQE_IDL EHEA_BMASK_IBM(0, 7)
+#define H_ALL_RES_QP_SWQE_IDL EHEA_BMASK_IBM(0, 7)
/* max swqe immediate data length */
-#define H_ALL_RES_QP_PORT_NUM EHEA_BMASK_IBM(48, 63)
+#define H_ALL_RES_QP_PORT_NUM EHEA_BMASK_IBM(48, 63)
/* input param R12 */
-#define H_ALL_RES_QP_TH_RQ2 EHEA_BMASK_IBM(0, 15)
+#define H_ALL_RES_QP_TH_RQ2 EHEA_BMASK_IBM(0, 15)
/* Threshold RQ2 */
-#define H_ALL_RES_QP_TH_RQ3 EHEA_BMASK_IBM(16, 31)
+#define H_ALL_RES_QP_TH_RQ3 EHEA_BMASK_IBM(16, 31)
/* Threshold RQ3 */
/* output param R6 */
-#define H_ALL_RES_QP_ACT_SWQE EHEA_BMASK_IBM(0, 15)
-#define H_ALL_RES_QP_ACT_R1WQE EHEA_BMASK_IBM(16, 31)
-#define H_ALL_RES_QP_ACT_R2WQE EHEA_BMASK_IBM(32, 47)
-#define H_ALL_RES_QP_ACT_R3WQE EHEA_BMASK_IBM(48, 63)
+#define H_ALL_RES_QP_ACT_SWQE EHEA_BMASK_IBM(0, 15)
+#define H_ALL_RES_QP_ACT_R1WQE EHEA_BMASK_IBM(16, 31)
+#define H_ALL_RES_QP_ACT_R2WQE EHEA_BMASK_IBM(32, 47)
+#define H_ALL_RES_QP_ACT_R3WQE EHEA_BMASK_IBM(48, 63)
/* output param, R7 */
-#define H_ALL_RES_QP_ACT_SSGE EHEA_BMASK_IBM(0, 7)
-#define H_ALL_RES_QP_ACT_R1SGE EHEA_BMASK_IBM(8, 15)
-#define H_ALL_RES_QP_ACT_R2SGE EHEA_BMASK_IBM(16, 23)
-#define H_ALL_RES_QP_ACT_R3SGE EHEA_BMASK_IBM(24, 31)
+#define H_ALL_RES_QP_ACT_SSGE EHEA_BMASK_IBM(0, 7)
+#define H_ALL_RES_QP_ACT_R1SGE EHEA_BMASK_IBM(8, 15)
+#define H_ALL_RES_QP_ACT_R2SGE EHEA_BMASK_IBM(16, 23)
+#define H_ALL_RES_QP_ACT_R3SGE EHEA_BMASK_IBM(24, 31)
#define H_ALL_RES_QP_ACT_SWQE_IDL EHEA_BMASK_IBM(32, 39)
/* output param R8,R9 */
-#define H_ALL_RES_QP_SIZE_SQ EHEA_BMASK_IBM(0, 31)
-#define H_ALL_RES_QP_SIZE_RQ1 EHEA_BMASK_IBM(32, 63)
-#define H_ALL_RES_QP_SIZE_RQ2 EHEA_BMASK_IBM(0, 31)
-#define H_ALL_RES_QP_SIZE_RQ3 EHEA_BMASK_IBM(32, 63)
+#define H_ALL_RES_QP_SIZE_SQ EHEA_BMASK_IBM(0, 31)
+#define H_ALL_RES_QP_SIZE_RQ1 EHEA_BMASK_IBM(32, 63)
+#define H_ALL_RES_QP_SIZE_RQ2 EHEA_BMASK_IBM(0, 31)
+#define H_ALL_RES_QP_SIZE_RQ3 EHEA_BMASK_IBM(32, 63)
/* output param R11,R12 */
-#define H_ALL_RES_QP_LIOBN_SQ EHEA_BMASK_IBM(0, 31)
-#define H_ALL_RES_QP_LIOBN_RQ1 EHEA_BMASK_IBM(32, 63)
-#define H_ALL_RES_QP_LIOBN_RQ2 EHEA_BMASK_IBM(0, 31)
-#define H_ALL_RES_QP_LIOBN_RQ3 EHEA_BMASK_IBM(32, 63)
+#define H_ALL_RES_QP_LIOBN_SQ EHEA_BMASK_IBM(0, 31)
+#define H_ALL_RES_QP_LIOBN_RQ1 EHEA_BMASK_IBM(32, 63)
+#define H_ALL_RES_QP_LIOBN_RQ2 EHEA_BMASK_IBM(0, 31)
+#define H_ALL_RES_QP_LIOBN_RQ3 EHEA_BMASK_IBM(32, 63)
u64 ehea_h_alloc_resource_qp(const u64 adapter_handle,
struct ehea_qp_init_attr *init_attr, const u32 pd,
@@ -334,28 +334,28 @@ u64 ehea_h_alloc_resource_cq(const u64 adapter_handle,
}
/* Defines for H_CALL H_ALLOC_RESOURCE */
-#define H_ALL_RES_TYPE_QP 1
-#define H_ALL_RES_TYPE_CQ 2
-#define H_ALL_RES_TYPE_EQ 3
-#define H_ALL_RES_TYPE_MR 5
-#define H_ALL_RES_TYPE_MW 6
+#define H_ALL_RES_TYPE_QP 1
+#define H_ALL_RES_TYPE_CQ 2
+#define H_ALL_RES_TYPE_EQ 3
+#define H_ALL_RES_TYPE_MR 5
+#define H_ALL_RES_TYPE_MW 6
/* input param R5 */
-#define H_ALL_RES_EQ_NEQ EHEA_BMASK_IBM(0, 0)
+#define H_ALL_RES_EQ_NEQ EHEA_BMASK_IBM(0, 0)
#define H_ALL_RES_EQ_NON_NEQ_ISN EHEA_BMASK_IBM(6, 7)
#define H_ALL_RES_EQ_INH_EQE_GEN EHEA_BMASK_IBM(16, 16)
-#define H_ALL_RES_EQ_RES_TYPE EHEA_BMASK_IBM(56, 63)
+#define H_ALL_RES_EQ_RES_TYPE EHEA_BMASK_IBM(56, 63)
/* input param R6 */
-#define H_ALL_RES_EQ_MAX_EQE EHEA_BMASK_IBM(32, 63)
+#define H_ALL_RES_EQ_MAX_EQE EHEA_BMASK_IBM(32, 63)
/* output param R6 */
-#define H_ALL_RES_EQ_LIOBN EHEA_BMASK_IBM(32, 63)
+#define H_ALL_RES_EQ_LIOBN EHEA_BMASK_IBM(32, 63)
/* output param R7 */
-#define H_ALL_RES_EQ_ACT_EQE EHEA_BMASK_IBM(32, 63)
+#define H_ALL_RES_EQ_ACT_EQE EHEA_BMASK_IBM(32, 63)
/* output param R8 */
-#define H_ALL_RES_EQ_ACT_PS EHEA_BMASK_IBM(32, 63)
+#define H_ALL_RES_EQ_ACT_PS EHEA_BMASK_IBM(32, 63)
/* output param R9 */
#define H_ALL_RES_EQ_ACT_EQ_IST_C EHEA_BMASK_IBM(30, 31)
@@ -453,12 +453,12 @@ u64 ehea_h_register_smr(const u64 adapter_handle, const u64 orig_mr_handle,
hret = ehea_plpar_hcall9(H_REGISTER_SMR,
outs,
- adapter_handle , /* R4 */
- orig_mr_handle, /* R5 */
- vaddr_in, /* R6 */
- (((u64)access_ctrl) << 32ULL), /* R7 */
- pd, /* R8 */
- 0, 0, 0, 0); /* R9-R12 */
+ adapter_handle , /* R4 */
+ orig_mr_handle, /* R5 */
+ vaddr_in, /* R6 */
+ (((u64)access_ctrl) << 32ULL), /* R7 */
+ pd, /* R8 */
+ 0, 0, 0, 0); /* R9-R12 */
mr->handle = outs[0];
mr->lkey = (u32)outs[2];
@@ -471,11 +471,11 @@ u64 ehea_h_disable_and_get_hea(const u64 adapter_handle, const u64 qp_handle)
u64 outs[PLPAR_HCALL9_BUFSIZE];
return ehea_plpar_hcall9(H_DISABLE_AND_GET_HEA,
- outs,
+ outs,
adapter_handle, /* R4 */
H_DISABLE_GET_EHEA_WQE_P, /* R5 */
qp_handle, /* R6 */
- 0, 0, 0, 0, 0, 0); /* R7-R12 */
+ 0, 0, 0, 0, 0, 0); /* R7-R12 */
}
u64 ehea_h_free_resource(const u64 adapter_handle, const u64 res_handle,
@@ -483,9 +483,9 @@ u64 ehea_h_free_resource(const u64 adapter_handle, const u64 res_handle,
{
return ehea_plpar_hcall_norets(H_FREE_RESOURCE,
adapter_handle, /* R4 */
- res_handle, /* R5 */
+ res_handle, /* R5 */
force_bit,
- 0, 0, 0, 0); /* R7-R10 */
+ 0, 0, 0, 0); /* R7-R10 */
}
u64 ehea_h_alloc_resource_mr(const u64 adapter_handle, const u64 vaddr,
@@ -493,13 +493,13 @@ u64 ehea_h_alloc_resource_mr(const u64 adapter_handle, const u64 vaddr,
const u32 pd, u64 *mr_handle, u32 *lkey)
{
u64 hret;
- u64 outs[PLPAR_HCALL9_BUFSIZE];
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
hret = ehea_plpar_hcall9(H_ALLOC_HEA_RESOURCE,
outs,
adapter_handle, /* R4 */
5, /* R5 */
- vaddr, /* R6 */
+ vaddr, /* R6 */
length, /* R7 */
(((u64) access_ctrl) << 32ULL), /* R8 */
pd, /* R9 */
@@ -619,8 +619,8 @@ u64 ehea_h_error_data(const u64 adapter_handle, const u64 ressource_handle,
void *rblock)
{
return ehea_plpar_hcall_norets(H_ERROR_DATA,
- adapter_handle, /* R4 */
- ressource_handle, /* R5 */
- virt_to_abs(rblock), /* R6 */
- 0, 0, 0, 0); /* R7-R12 */
+ adapter_handle, /* R4 */
+ ressource_handle, /* R5 */
+ virt_to_abs(rblock), /* R6 */
+ 0, 0, 0, 0); /* R7-R12 */
}
diff --git a/drivers/net/ehea/ehea_phyp.h b/drivers/net/ehea/ehea_phyp.h
index faa191d..f3628c8 100644
--- a/drivers/net/ehea/ehea_phyp.h
+++ b/drivers/net/ehea/ehea_phyp.h
@@ -93,7 +93,7 @@ static inline void hcp_epas_ctor(struct h_epas *epas, u64 paddr_kernel,
static inline void hcp_epas_dtor(struct h_epas *epas)
{
if (epas->kernel.addr)
- iounmap((void __iomem*)((u64)epas->kernel.addr & PAGE_MASK));
+ iounmap((void __iomem *)((u64)epas->kernel.addr & PAGE_MASK));
epas->user.addr = 0;
epas->kernel.addr = 0;
@@ -388,23 +388,23 @@ u64 ehea_h_modify_ehea_qp(const u64 adapter_handle,
const u64 qp_handle,
const u64 sel_mask,
void *cb_addr,
- u64 * inv_attr_id,
- u64 * proc_mask, u16 * out_swr, u16 * out_rwr);
+ u64 *inv_attr_id,
+ u64 *proc_mask, u16 *out_swr, u16 *out_rwr);
u64 ehea_h_alloc_resource_eq(const u64 adapter_handle,
- struct ehea_eq_attr *eq_attr, u64 * eq_handle);
+ struct ehea_eq_attr *eq_attr, u64 *eq_handle);
u64 ehea_h_alloc_resource_cq(const u64 adapter_handle,
struct ehea_cq_attr *cq_attr,
- u64 * cq_handle, struct h_epas *epas);
+ u64 *cq_handle, struct h_epas *epas);
u64 ehea_h_alloc_resource_qp(const u64 adapter_handle,
struct ehea_qp_init_attr *init_attr,
const u32 pd,
- u64 * qp_handle, struct h_epas *h_epas);
+ u64 *qp_handle, struct h_epas *h_epas);
-#define H_REG_RPAGE_PAGE_SIZE EHEA_BMASK_IBM(48,55)
-#define H_REG_RPAGE_QT EHEA_BMASK_IBM(62,63)
+#define H_REG_RPAGE_PAGE_SIZE EHEA_BMASK_IBM(48, 55)
+#define H_REG_RPAGE_QT EHEA_BMASK_IBM(62, 63)
u64 ehea_h_register_rpage(const u64 adapter_handle,
const u8 pagesize,
@@ -426,7 +426,7 @@ u64 ehea_h_free_resource(const u64 adapter_handle, const u64 res_handle,
u64 ehea_h_alloc_resource_mr(const u64 adapter_handle, const u64 vaddr,
const u64 length, const u32 access_ctrl,
- const u32 pd, u64 * mr_handle, u32 * lkey);
+ const u32 pd, u64 *mr_handle, u32 *lkey);
u64 ehea_h_register_rpage_mr(const u64 adapter_handle, const u64 mr_handle,
const u8 pagesize, const u8 queue_type,
@@ -439,8 +439,8 @@ u64 ehea_h_register_smr(const u64 adapter_handle, const u64 orig_mr_handle,
u64 ehea_h_query_ehea(const u64 adapter_handle, void *cb_addr);
/* output param R5 */
-#define H_MEHEAPORT_CAT EHEA_BMASK_IBM(40,47)
-#define H_MEHEAPORT_PN EHEA_BMASK_IBM(48,63)
+#define H_MEHEAPORT_CAT EHEA_BMASK_IBM(40, 47)
+#define H_MEHEAPORT_PN EHEA_BMASK_IBM(48, 63)
u64 ehea_h_query_ehea_port(const u64 adapter_handle, const u16 port_num,
const u8 cb_cat, const u64 select_mask,
--
1.5.3.8
^ 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