* [PATCH RFC 3/6] skbuff: convert to skb_orphan_frags
From: Michael S. Tsirkin @ 2012-05-07 13:54 UTC (permalink / raw)
To: Ian Campbell; +Cc: David Miller, netdev@vger.kernel.org, eric.dumazet@gmail.com
In-Reply-To: <cover.1336397823.git.mst@redhat.com>
Reduce dode duplication a bit using the new helper.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
net/core/skbuff.c | 22 ++++++++--------------
1 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index bd28e80..bdf5b09 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -785,10 +785,8 @@ struct sk_buff *skb_clone(struct sk_buff *skb, gfp_t gfp_mask)
{
struct sk_buff *n;
- if (skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY) {
- if (skb_copy_ubufs(skb, gfp_mask))
- return NULL;
- }
+ if (skb_orphan_frags(skb, gfp_mask))
+ return NULL;
n = skb + 1;
if (skb->fclone == SKB_FCLONE_ORIG &&
@@ -908,12 +906,10 @@ struct sk_buff *__pskb_copy(struct sk_buff *skb, int headroom, gfp_t gfp_mask)
if (skb_shinfo(skb)->nr_frags) {
int i;
- if (skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY) {
- if (skb_copy_ubufs(skb, gfp_mask)) {
- kfree_skb(n);
- n = NULL;
- goto out;
- }
+ if (skb_orphan_frags(skb, gfp_mask)) {
+ kfree_skb(n);
+ n = NULL;
+ goto out;
}
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
skb_shinfo(n)->frags[i] = skb_shinfo(skb)->frags[i];
@@ -1005,10 +1001,8 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
skb_free_head(skb);
} else {
/* copy this zero copy skb frags */
- if (skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY) {
- if (skb_copy_ubufs(skb, gfp_mask))
- goto nofrags;
- }
+ if (skb_orphan_frags(skb, gfp_mask))
+ goto nofrags;
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
skb_frag_ref(skb, i);
--
MST
^ permalink raw reply related
* [PATCH RFC 4/6] tun: orphan frags on xmit
From: Michael S. Tsirkin @ 2012-05-07 13:54 UTC (permalink / raw)
To: Ian Campbell; +Cc: David Miller, netdev@vger.kernel.org, eric.dumazet@gmail.com
In-Reply-To: <cover.1336397823.git.mst@redhat.com>
tun xmit is actually receive of the internal tun
socket. Orphan the frags same as we do for normal rx path.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/net/tun.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index bb8c72c..1ccbfd0 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -414,6 +414,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
/* Orphan the skb - required as we might hang on to it
* for indefinite time. */
+ if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC)))
+ goto drop;
skb_orphan(skb);
/* Enqueue packet */
--
MST
^ permalink raw reply related
* [PATCH RFC 5/6] net: orphan frags on receive
From: Michael S. Tsirkin @ 2012-05-07 13:54 UTC (permalink / raw)
To: Ian Campbell; +Cc: David Miller, netdev@vger.kernel.org, eric.dumazet@gmail.com
In-Reply-To: <cover.1336397823.git.mst@redhat.com>
zero copy packets are normally sent to the outside
network, but bridging, tun etc might loop them
back to host networking stack. If this happens
destructors will never be called, so orphan
the frags immediately on receive.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
net/core/dev.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index a2be59f..c0cdc00 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1630,6 +1630,8 @@ static inline int deliver_skb(struct sk_buff *skb,
struct packet_type *pt_prev,
struct net_device *orig_dev)
{
+ if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC)))
+ return -ENOMEM;
atomic_inc(&skb->users);
return pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
}
--
MST
^ permalink raw reply related
* [PATCH RFC 6/6] skbuff: set zerocopy flag on frag destructor
From: Michael S. Tsirkin @ 2012-05-07 13:54 UTC (permalink / raw)
To: Ian Campbell; +Cc: David Miller, netdev@vger.kernel.org, eric.dumazet@gmail.com
In-Reply-To: <cover.1336397823.git.mst@redhat.com>
set tx flags when adding a frag destructor to
force frags to be orphaned as appropriate.
copy when copying frags between skbs.
Note: rare false positives (where flag is set with no
destructors) are harmless.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/linux/skbuff.h | 19 ++++++++++++++++++-
net/core/skbuff.c | 3 +++
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 28d842e..2876e4d 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -258,6 +258,13 @@ enum {
SKBTX_WIFI_STATUS = 1 << 5,
};
+static inline void skb_copy_frag_destructor(struct sk_buff *to,
+ struct sk_buff *from)
+{
+ skb_shinfo(to)->tx_flags |= skb_shinfo(from)->tx_flags &
+ SKBTX_DEV_ZEROCOPY;
+}
+
/*
* The callback notifies userspace to release buffers when skb DMA is done in
* lower device, the skb last reference should be 0 when calling this.
@@ -1260,6 +1267,8 @@ static inline void skb_frag_set_destructor(struct sk_buff *skb, int i,
{
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
frag->page.destructor = destroy;
+ if (destroy)
+ skb_shinfo(skb)->tx_flags |= SKBTX_DEV_ZEROCOPY;
}
/**
@@ -1726,7 +1735,15 @@ static inline int skb_orphan_frags(struct sk_buff *skb, gfp_t gfp_mask)
return skb_copy_ubufs(skb, gfp_mask);
}
-
+/**
+ * skb_copy_frag_destructor - update skb after destructor copy
+ * @to: target skb to which frags were copied
+ * @from: source skb from which frags where copied
+ *
+ * Called after some frags move between skbs.
+ * If any frags in @from have a destructor, a flag in tx_flags is set.
+ * Set flag for @to so that it gets checked for destructors.
+ */
static inline void skb_copy_frag_destructor(struct sk_buff *to,
struct sk_buff *from)
{
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index bdf5b09..83b04d9 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -902,6 +902,7 @@ struct sk_buff *__pskb_copy(struct sk_buff *skb, int headroom, gfp_t gfp_mask)
n->truesize += skb->data_len;
n->data_len = skb->data_len;
n->len = skb->len;
+ skb_copy_frag_destructor(n, skb);
if (skb_shinfo(skb)->nr_frags) {
int i;
@@ -2302,6 +2303,7 @@ static inline void skb_split_no_header(struct sk_buff *skb,
void skb_split(struct sk_buff *skb, struct sk_buff *skb1, const u32 len)
{
int pos = skb_headlen(skb);
+ skb_copy_frag_destructor(skb1, skb);
if (len < pos) /* Split line is inside header. */
skb_split_inside_header(skb, skb1, len, pos);
@@ -2781,6 +2783,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
if (unlikely(!nskb))
goto err;
+ skb_copy_frag_destructor(nskb, skb);
skb_reserve(nskb, headroom);
__skb_put(nskb, doffset);
}
--
MST
^ permalink raw reply related
* Re: [PATCH] net: compare_ether_addr[_64bits]() has no ordering
From: Johannes Berg @ 2012-05-07 14:12 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1336398809.3752.2313.camel@edumazet-glaptop>
On Mon, 2012-05-07 at 15:53 +0200, Eric Dumazet wrote:
> On Mon, 2012-05-07 at 15:39 +0200, Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > Neither compare_ether_addr() nor compare_ether_addr_64bits()
> > (as it can fall back to the former) have comparison semantics
> > like memcmp() where the sign of the return value indicates sort
> > order. We had a bug in the wireless code due to a blind memcmp
> > replacement because of this.
> >
> > A cursory look suggests that the wireless bug was the only one
> > due to this semantic difference.
> >
> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> > ---
> > include/linux/etherdevice.h | 11 ++++++-----
> > 1 file changed, 6 insertions(+), 5 deletions(-)
>
> The right way to avoid this kind of problems is to change these
> functions to return a bool
Well, I guess so, but that'd be a weird thing for a compare_ function...
should probably be named equal_... then, but I'm not really able to do
such a huge change on the first day after my vacation :-)
johannes
^ permalink raw reply
* Re: [PATCH net] cdc_ether: add Novatel USB551L device IDs for FLAG_WWAN
From: Oliver Neukum @ 2012-05-07 14:23 UTC (permalink / raw)
To: Dan Williams
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1336400691.2385.10.camel-wKZy7rqYPVb5EHUCmHmTqw@public.gmane.org>
Am Montag, 7. Mai 2012, 16:24:51 schrieb Dan Williams:
> Needs to be tagged with FLAG_WWAN, which since it has generic
> descriptors, won't happen if we don't override the generic
> driver info.
>
> Cc: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Acked-by: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net] cdc_ether: add Novatel USB551L device IDs for FLAG_WWAN
From: Dan Williams @ 2012-05-07 14:24 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Oliver Neukum,
stable-u79uwXL29TY76Z2rM5mHXA
Needs to be tagged with FLAG_WWAN, which since it has generic
descriptors, won't happen if we don't override the generic
driver info.
Cc: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
drivers/net/usb/cdc_ether.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 90a3002..41cd7da 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -475,6 +475,7 @@ static const struct driver_info wwan_info = {
/*-------------------------------------------------------------------------*/
#define HUAWEI_VENDOR_ID 0x12D1
+#define NOVATEL_VENDOR_ID 0x1410
static const struct usb_device_id products [] = {
/*
@@ -592,6 +593,21 @@ static const struct usb_device_id products [] = {
* because of bugs/quirks in a given product (like Zaurus, above).
*/
{
+ /* Novatel USB551L */
+ /* This match must come *before* the generic CDC-ETHER match so that
+ * we get FLAG_WWAN set on the device, since it's descriptors are
+ * generic CDC-ETHER.
+ */
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
+ | USB_DEVICE_ID_MATCH_PRODUCT
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = NOVATEL_VENDOR_ID,
+ .idProduct = 0xB001,
+ .bInterfaceClass = USB_CLASS_COMM,
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ .driver_info = (unsigned long)&wwan_info,
+}, {
USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ETHERNET,
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info,
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [v12 PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
From: Pablo Neira Ayuso @ 2012-05-07 14:54 UTC (permalink / raw)
To: Hans Schillstrom
Cc: kaber@trash.net, jengelh@medozas.de,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org,
hans@schillstrom.com
In-Reply-To: <201205071457.32127.hans.schillstrom@ericsson.com>
On Mon, May 07, 2012 at 02:57:30PM +0200, Hans Schillstrom wrote:
> On Monday 07 May 2012 14:22:32 Pablo Neira Ayuso wrote:
> > On Mon, May 07, 2012 at 02:09:46PM +0200, Hans Schillstrom wrote:
> > > On Monday 07 May 2012 13:56:12 Pablo Neira Ayuso wrote:
> > > > On Mon, May 07, 2012 at 11:14:34AM +0200, Hans Schillstrom wrote:
> > > > > > > We have plenty of rules where just source port mask is zero.
> > > > > > > and the dest-port-mask is 0xfffc (or 0xffff)
> > > > > >
> > > > > > 0xffff and 0x0000 means on/off respectively.
> > > > > >
> > > > > > Still curious, how can 0xfffc be useful?
> > > > >
> > > > > That's a special case where an appl is using 4 ports.
> > > > > But in general, have not seen other than "on/off" except for above.
> > > >
> > > > I see. Well I'm fine with this way to switch on/off things, just
> > > > wanted some clafication.
> > > >
> > > > Still one final thing I'd like to remove before inclusion:
> > > >
> > > > + union hmark_ports port_mask;
> > > > + union hmark_ports port_set;
> > > > + __u32 spi_mask;
> > > > + __u32 spi_set;
> > > >
> > > > the spi_mask seems redundant. The port_mask already provides u32 for
> > > > it.
> > >
> > > No problems, I'll remove it.
> >
> > OK. As a nice side-effect, this will lead to removing the branch that
> > tests ESP/AH in hmark_set_tuple_ports.
> >
> Yes, only check if not ESP or AH to swap src/dst
Do you really that branch? I mean, unless I'm missing anything, swapping
them shouldn't be a problem.
^ permalink raw reply
* Re: New commands to configure IOV features
From: Greg Rose @ 2012-05-07 15:16 UTC (permalink / raw)
To: Yuval Mintz; +Cc: Ben Hutchings, netdev@vger.kernel.org
In-Reply-To: <4FA7AF62.8000405@broadcom.com>
On Mon, 7 May 2012 14:17:54 +0300
Yuval Mintz <yuvalmin@broadcom.com> wrote:
> I've tried to figure out if there was a standard interface
> (ethtool/iproute) through which a user could configure the number
> of vfs in his system.
>
> I've seen the RFC suggested in
> http://markmail.org/thread/qblfcv7zbxsxp7q6, and
> http://markmail.org/thread/fw54dcppmxuxoe6n, but failed to see any
> later references to it (commits or further discussion on this topic).
>
> How exactly are things standing with these RFCs? Were they abandoned?
The only way to configure the number of VFs continues to be through the
max_vfs module parameter. I've got a patch to do it through ethtool
sitting on the back burner but due to other requirements of my day job
I've not been able to work on it since last fall.
- Greg
>
> Thanks,
> Yuval
>
> --
> 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
* Re: [PATCH] mwl8k: Add 0x2a02 PCI device-id (Marvell 88W8361)
From: Dan Williams @ 2012-05-07 16:09 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: sedat.dilek, John W. Linville, linux-wireless, netdev,
linux-kernel, lautriv, Jim Cromie
In-Reply-To: <20120501125102.GN3157@wantstofly.org>
On Tue, 2012-05-01 at 14:51 +0200, Lennert Buytenhek wrote:
> On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote:
>
> > > On 1st sight, logs look fine:
> > >
> > > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4,
> > > 00173f3bdde3, STA firmware 2.1.4.25
> > >
> > > But WLAN connection is not that fast and stable as lautriv reports
> > > (several abnormalities were observed).
> > >
> > > I requested a tarball which includes:
> > > * dmesg (Linux-3.3.3)
> > > * e_n_a (/etc/network/interfaces)
> > > * ifconfig output
> > > * iwconfig output
> > > * iw_phy output
> > > * ps_axu (WPA) output
> > >
> > > lautriv will be so kind to be around on #linux-wireless/Freenode the
> > > next days (UTC+2: German/Swiss local-time).
> > > Just ping him.
> > >
> > > Hope you have fun, together!
> > >
> > > - Sedat -
> >
> > A new tarball from lautriv with same outputs as before, but now tested
> > with Linux-3.4-rc4.
>
> The output looks good enough for me to ACK adding the PCI ID.
>
> Can the firmware being used here be submitted to the linux-firmware
> git tree?
So Marvell sent John a driver for TopDog a long time ago, which he put
up on kernel.org. That driver was reworked by Louis and put up in a git
tree, but both were lost to the kernel.org hack. I have git backups of
both git trees. I put Louis' cleanup here:
http://people.redhat.com/dcbw/mrvl_cb82.tar.bz2
That driver (mrvl_cb82) has the following PCI IDs:
static const struct pci_device_id mwl_id_tbl[] __devinitdata = {
{ PCI_VDEVICE(MARVELL, 0x2a02), 0 },
{ PCI_VDEVICE(MARVELL, 0x2a03), 1 },
{ PCI_VDEVICE(MARVELL, 0x2a06), 2 },
{ PCI_VDEVICE(MARVELL, 0x2a07), 3 },
{ PCI_VDEVICE(MARVELL, 0x2a04), 4 },
{ PCI_VDEVICE(MARVELL, 0x2a08), 5 },
{ PCI_VDEVICE(MARVELL, 0x2a0a), 6 },
{ PCI_VDEVICE(MARVELL, 0x2a0b), 7 },
{ PCI_VDEVICE(MARVELL, 0x2a0c), 8 },
{ 0 }
};
and supposedly works for CB82 + CB85. The firmware helper for CB82
looks pretty close to the mwl8k one.
The firmware API exposed by mrvl_cb82 looks very close to mwl8k
actually. I only checked the HostCmd bits, not the structures, so I
would expect a few differences. There are some commands that mwl8k
exposes that mrvl_cb82 does not and vice versa, but I'm not sure if the
drivers actually use those commands.
Hope this helps.
Dan
^ permalink raw reply
* Re: [net-next 0/4][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-05-07 16:33 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1336374778.2386.1.camel@jtkirshe-mobl>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 07 May 2012 00:12:58 -0700
> On Sun, 2012-05-06 at 13:25 -0400, David Miller wrote:
>> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Date: Sat, 5 May 2012 05:38:09 -0700
>>
>> > This series of patches contains updates for e1000e and ixgbe.
>> >
>> > NOTE- The ixgbe patch can and probably should be applied to
>> > David Miller's net tree as well.
>> >
>> > The following are changes since commit bd14b1b2e29bd6812597f896dde06eaf7c6d2f24:
>> > tcp: be more strict before accepting ECN negociation
>> > and are available in the git repository at:
>> > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
>>
>> No new changes there?
>>
>> [davem@drr net-next]$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
>> From git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next
>> * branch master -> FETCH_HEAD
>> Already up-to-date.
>
> Sorry Dave, I thought I had pushed the changes but it appears I did not.
> I have rectified that and now my net-next tree contains the four
> patches.
That looks better, pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] mwl8k: Add 0x2a02 PCI device-id (Marvell 88W8361)
From: Dan Williams @ 2012-05-07 16:42 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: sedat.dilek-Re5JQEeQqe8AvxtiuMwx3w, John W. Linville,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, lautriv, Jim Cromie
In-Reply-To: <1336406944.2385.24.camel-wKZy7rqYPVb5EHUCmHmTqw@public.gmane.org>
On Mon, 2012-05-07 at 11:09 -0500, Dan Williams wrote:
> On Tue, 2012-05-01 at 14:51 +0200, Lennert Buytenhek wrote:
> > On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote:
> >
> > > > On 1st sight, logs look fine:
> > > >
> > > > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4,
> > > > 00173f3bdde3, STA firmware 2.1.4.25
> > > >
> > > > But WLAN connection is not that fast and stable as lautriv reports
> > > > (several abnormalities were observed).
> > > >
> > > > I requested a tarball which includes:
> > > > * dmesg (Linux-3.3.3)
> > > > * e_n_a (/etc/network/interfaces)
> > > > * ifconfig output
> > > > * iwconfig output
> > > > * iw_phy output
> > > > * ps_axu (WPA) output
> > > >
> > > > lautriv will be so kind to be around on #linux-wireless/Freenode the
> > > > next days (UTC+2: German/Swiss local-time).
> > > > Just ping him.
> > > >
> > > > Hope you have fun, together!
> > > >
> > > > - Sedat -
> > >
> > > A new tarball from lautriv with same outputs as before, but now tested
> > > with Linux-3.4-rc4.
> >
> > The output looks good enough for me to ACK adding the PCI ID.
> >
> > Can the firmware being used here be submitted to the linux-firmware
> > git tree?
>
> So Marvell sent John a driver for TopDog a long time ago, which he put
> up on kernel.org. That driver was reworked by Louis and put up in a git
> tree, but both were lost to the kernel.org hack. I have git backups of
> both git trees. I put Louis' cleanup here:
>
> http://people.redhat.com/dcbw/mrvl_cb82.tar.bz2
>
> That driver (mrvl_cb82) has the following PCI IDs:
>
> static const struct pci_device_id mwl_id_tbl[] __devinitdata = {
> { PCI_VDEVICE(MARVELL, 0x2a02), 0 },
> { PCI_VDEVICE(MARVELL, 0x2a03), 1 },
> { PCI_VDEVICE(MARVELL, 0x2a06), 2 },
> { PCI_VDEVICE(MARVELL, 0x2a07), 3 },
> { PCI_VDEVICE(MARVELL, 0x2a04), 4 },
> { PCI_VDEVICE(MARVELL, 0x2a08), 5 },
> { PCI_VDEVICE(MARVELL, 0x2a0a), 6 },
> { PCI_VDEVICE(MARVELL, 0x2a0b), 7 },
> { PCI_VDEVICE(MARVELL, 0x2a0c), 8 },
> { 0 }
> };
>
> and supposedly works for CB82 + CB85. The firmware helper for CB82
> looks pretty close to the mwl8k one.
>
> The firmware API exposed by mrvl_cb82 looks very close to mwl8k
> actually. I only checked the HostCmd bits, not the structures, so I
> would expect a few differences. There are some commands that mwl8k
> exposes that mrvl_cb82 does not and vice versa, but I'm not sure if the
> drivers actually use those commands.
As for AP mode, the Marvell Extranet does have AP-mode drivers for the
8361 and 8363, but the zipfiles are password-protected and I have no
idea what license they are supposed to be under due to that. Thus I
cannot get the AP mode firmware for those either to submit to
linux-firmware.
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] pch_gbe: Adding read memory barriers
From: Erwan Velu @ 2012-05-07 17:39 UTC (permalink / raw)
To: netdev, linux-kernel, stable, tshimizu818
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
Dear Linux Kernel Developers,
Please find attached, a patch to solve "Received CRC" errors reported by
the pch_gbe driver under heavy load. It occurred on an Intel ATOM E620T
while running a 300mbit/sec multicast network stream leading to a ~100%
cpu usage.
This patch got validated on the 3.2.16 kernel but also apply to the 3.x
family.
Getting it into stable would be perfect as it solves reliability issues.
Cheers,
Erwan Velu
[-- Attachment #2: 0001-pch_gbe-Adding-read-memory-barriers.patch --]
[-- Type: application/octet-stream, Size: 1805 bytes --]
From 3b65802e4c5a8827a84022066f10dec4d61c1f22 Mon Sep 17 00:00:00 2001
From: Erwan Velu <erwan.velu@zodiacaerospace.com>
Date: Mon, 7 May 2012 14:53:17 +0200
Subject: [PATCH 1/1] pch_gbe: Adding read memory barriers
Under a strong incoming packet stream and/or high cpu usage,
the pch_gbe driver reports "Receive CRC Error" and discards packet.
Adding rmb() calls before considering the network card's status solve
this issues.
Signed-off-by: Erwan Velu <erwan.velu@zodiacaerospace.com>
---
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 48406ca..7746ca3 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -1222,6 +1222,8 @@ static irqreturn_t pch_gbe_intr(int irq, void *data)
}
}
+ smp_rmb(); /* prevent any other reads before*/
+
/* When request status is Receive interruption */
if ((int_st & (PCH_GBE_INT_RX_DMA_CMPLT | PCH_GBE_INT_TX_CMPLT)) ||
(adapter->rx_stop_flag == true)) {
@@ -1390,6 +1392,9 @@ pch_gbe_clean_tx(struct pch_gbe_adapter *adapter,
i = tx_ring->next_to_clean;
tx_desc = PCH_GBE_TX_DESC(*tx_ring, i);
+
+ rmb(); /* prevent any other reads before*/
+
pr_debug("gbec_status:0x%04x dma_status:0x%04x\n",
tx_desc->gbec_status, tx_desc->dma_status);
@@ -1490,6 +1495,9 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
while (*work_done < work_to_do) {
/* Check Rx descriptor status */
rx_desc = PCH_GBE_RX_DESC(*rx_ring, i);
+
+ rmb(); /* prevent any other reads before*/
+
if (rx_desc->gbec_status == DSC_INIT16)
break;
cleaned = true;
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] pch_gbe: Adding read memory barriers
From: David Miller @ 2012-05-07 17:44 UTC (permalink / raw)
To: erwanaliasr1; +Cc: netdev, linux-kernel, stable, tshimizu818
In-Reply-To: <4FA808E3.1030908@gmail.com>
From: Erwan Velu <erwanaliasr1@gmail.com>
Date: Mon, 07 May 2012 19:39:47 +0200
> Please find attached
First of all, for a patch which is not accepted yet you do not
CC: stable.
Second of all, do not put text in the main body of your email which is
unrelated to the patch and should not end up in the commit message.
Instead, post your patch to the appropriate primary mailing lists,
and if it's accepted it can then be submitted to -stable at some
later time.
Your patch posting email should be composed purely of the commit
log message in the message body, followed by the actual patch.
Otherwise the maintainer that applies your patch has to edit out
all of this other flowery text that is unrelated to the commit
and that makes more work for them.
^ permalink raw reply
* [PATCH] pch_gbe: Adding read memory barriers
From: Erwan Velu @ 2012-05-07 17:49 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: tshimizu818
From 3b65802e4c5a8827a84022066f10dec4d61c1f22 Mon Sep 17 00:00:00 2001
From: Erwan Velu <erwan.velu@zodiacaerospace.com>
Date: Mon, 7 May 2012 14:53:17 +0200
Subject: [PATCH 1/1] pch_gbe: Adding read memory barriers
Under a strong incoming packet stream and/or high cpu usage,
the pch_gbe driver reports "Receive CRC Error" and discards packet.
It occurred on an Intel ATOM E620T while running a 300mbit/sec multicast
network stream leading to a ~100% cpu usage.
Adding rmb() calls before considering the network card's status solve
this issues.
This patch got validated on the 3.2.16 kernel but also apply to the 3.x
family.
Getting it into stable would be perfect as it solves reliability issues.
Signed-off-by: Erwan Velu <erwan.velu@zodiacaerospace.com>
---
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 48406ca..7746ca3 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -1222,6 +1222,8 @@ static irqreturn_t pch_gbe_intr(int irq, void *data)
}
}
+ smp_rmb(); /* prevent any other reads before*/
+
/* When request status is Receive interruption */
if ((int_st & (PCH_GBE_INT_RX_DMA_CMPLT | PCH_GBE_INT_TX_CMPLT)) ||
(adapter->rx_stop_flag == true)) {
@@ -1390,6 +1392,9 @@ pch_gbe_clean_tx(struct pch_gbe_adapter *adapter,
i = tx_ring->next_to_clean;
tx_desc = PCH_GBE_TX_DESC(*tx_ring, i);
+
+ rmb(); /* prevent any other reads before*/
+
pr_debug("gbec_status:0x%04x dma_status:0x%04x\n",
tx_desc->gbec_status, tx_desc->dma_status);
@@ -1490,6 +1495,9 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
while (*work_done < work_to_do) {
/* Check Rx descriptor status */
rx_desc = PCH_GBE_RX_DESC(*rx_ring, i);
+
+ rmb(); /* prevent any other reads before*/
+
if (rx_desc->gbec_status == DSC_INIT16)
break;
cleaned = true;
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] pch_gbe: Adding read memory barriers
From: David Miller @ 2012-05-07 17:57 UTC (permalink / raw)
To: erwanaliasr1; +Cc: netdev, linux-kernel, tshimizu818
In-Reply-To: <4FA80B46.5070405@gmail.com>
Your patch doesn't apply to the net-next tree which is what you should
be basing all of your networking patches on:
[davem@bql net-next]$ git am --signoff pch_gbe-Adding-read-memory-barriers.patch
Applying: pch_gbe: Adding read memory barriers
error: patch failed: drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c:1222
error: drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c: patch does not apply
Patch failed at 0001 pch_gbe: Adding read memory barriers
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
Stop rushing things and take your time learning the process.
Otherwise you're going to make more work for maintainers and they
end up grumpy as a result, which you don't want.
^ permalink raw reply
* Re: [PATCH] mwl8k: Add 0x2a02 PCI device-id (Marvell 88W8361)
From: Adrian Chadd @ 2012-05-07 18:26 UTC (permalink / raw)
To: Dan Williams
Cc: Lennert Buytenhek, sedat.dilek, John W. Linville, linux-wireless,
netdev, linux-kernel, lautriv, Jim Cromie
In-Reply-To: <1336408965.2385.25.camel@dcbw.foobar.com>
Hi,
Let me see if the topdog firmware that FreeBSD ships with supports hostap mode.
I'm having aggregation issues but I think that's driver side, not firmware side.
Adrian
^ permalink raw reply
* Re: Netlink for kernel<->user space communication?
From: Arvid Brodin @ 2012-05-07 18:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
On Tue, 24 Apr 2012 16:57:55 -0700
Stephen Hemminger <shemminger@xxxxxxxxxx> wrote:
> On Tue, 24 Apr 2012 23:52:34 +0000
> Arvid Brodin <Arvid.Brodin@xxxxxxxx> wrote:
>
>> Hi.
>>
>> I'm writing a kernel driver for the HSR protocol, a standard for high availability
>> networks. I want to send messages from the kernel to user space about broken network
>> links. I also want user space to be able to ask the kernel about its view of the status of
>> nodes on the network.
>>
>> Netlink seems like a good tool for this. (Is it?)
>
> Yes.
>
>> But do I use raw netlink? (Described here: http://www.linuxjournal.com/article/7356 - but
>> this seems a bit out of date, the kernel API description differs from today's kernel
>> implementation.)
>
> No. Your driver probably looks like a device so you should be
> using rtnetlink messages.
I'm already using rtnetlink messages to add and remove my device, which works fine (see
e.g. http://www.spinics.net/lists/netdev/msg192817.html - although I didn't think it
meaningful to include the iproute2 patch here, until the kernel part is ready).
The protocol specifies transmission of "supervision frames" every 2 seconds, e.g. to check
link integrity. Every such frame should be received from two directions in the ring - if
only one is received, then there is a link problem.
I'd like to notify user space about every such occurence. Is there a rtnetlink message
type that fits this? The stuff in rtnetlink.h seems to be mostly concerned with specific
user space commands (there is something called RTNLGRP_NOTIFY but I couldn't find any
instances of it being used in the kernel, nor any documentation).
>> Or do I use the "Kernel Connector" (Documentation/connector/connector.txt)?
> no.
Your reply didn't reach me for some reason - I found it just yesterday on spinics - and in
the meantime I've implemented the notification using the connector protocol... :-|
--
Arvid Brodin
Enea Services Stockholm AB - since February 16 a part of Xdin in the Alten Group. Soon we
will be working under the common brand name Xdin. Read more at www.xdin.com.
^ permalink raw reply
* Re[2]: [v12 PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
From: Hans Schillstrom @ 2012-05-07 19:09 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Hans Schillstrom, kaber@trash.net, jengelh@medozas.de,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
>On Mon, May 07, 2012 at 02:57:30PM +0200, Hans Schillstrom wrote:
>> On Monday 07 May 2012 14:22:32 Pablo Neira Ayuso wrote:
>> > On Mon, May 07, 2012 at 02:09:46PM +0200, Hans Schillstrom wrote:
>> > > On Monday 07 May 2012 13:56:12 Pablo Neira Ayuso wrote:
>> > > > On Mon, May 07, 2012 at 11:14:34AM +0200, Hans Schillstrom wrote:
>> > > > > > > We have plenty of rules where just source port mask is zero.
>> > > > > > > and the dest-port-mask is 0xfffc (or 0xffff)
>> > > > > >
>> > > > > > 0xffff and 0x0000 means on/off respectively.
>> > > > > >
>> > > > > > Still curious, how can 0xfffc be useful?
>> > > > >
>> > > > > That's a special case where an appl is using 4 ports.
>> > > > > But in general, have not seen other than "on/off" except for above.
>> > > >
>> > > > I see. Well I'm fine with this way to switch on/off things, just
>> > > > wanted some clafication.
>> > > >
>> > > > Still one final thing I'd like to remove before inclusion:
>> > > >
>> > > > + union hmark_ports port_mask;
>> > > > + union hmark_ports port_set;
>> > > > + __u32 spi_mask;
>> > > > + __u32 spi_set;
>> > > >
>> > > > the spi_mask seems redundant. The port_mask already provides u32 for
>> > > > it.
>> > >
>> > > No problems, I'll remove it.
>> >
>> > OK. As a nice side-effect, this will lead to removing the branch that
>> > tests ESP/AH in hmark_set_tuple_ports.
>> >
>> Yes, only check if not ESP or AH to swap src/dst
>
>Do you really that branch? I mean, unless I'm missing anything, swapping
>them shouldn't be a problem.
Well,
that was just to keep backward compatibility and make my tests happy.
I'll remove them and change my test setup.
^ permalink raw reply
* [PATCH] pch_gbe: Adding read memory barriers
From: Erwan Velu @ 2012-05-07 19:30 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: tshimizu818
From bb1e271db0fa1a29df19bede69faf8004389132d Mon Sep 17 00:00:00 2001
From: Erwan Velu <erwan.velu@zodiacaerospace.com>
Date: Mon, 7 May 2012 19:15:29 +0000
Subject: [PATCH 1/1] pch_gbe: Adding read memory barriers
Under a strong incoming packet stream and/or high cpu usage,
the pch_gbe driver reports "Receive CRC Error" and discards packet.
It occurred on an Intel ATOM E620T while running a 300mbit/sec multicast
network stream leading to a ~100% cpu usage.
Adding rmb() calls before considering the network card's status solve
this issue.
Getting it into stable would be perfect as it solves reliability issues.
Signed-off-by: Erwan Velu <erwan.velu@zodiacaerospace.com>
---
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 8035e5f..ace3654 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -1413,6 +1413,7 @@ static irqreturn_t pch_gbe_intr(int irq, void *data)
pch_gbe_mac_set_pause_packet(hw);
}
}
+ smp_rmb(); /* prevent any other reads before*/
/* When request status is Receive interruption */
if ((int_st & (PCH_GBE_INT_RX_DMA_CMPLT | PCH_GBE_INT_TX_CMPLT)) ||
@@ -1582,6 +1584,7 @@ pch_gbe_clean_tx(struct pch_gbe_adapter *adapter,
i = tx_ring->next_to_clean;
tx_desc = PCH_GBE_TX_DESC(*tx_ring, i);
+ rmb(); /* prevent any other reads before*/
pr_debug("gbec_status:0x%04x dma_status:0x%04x\n",
tx_desc->gbec_status, tx_desc->dma_status);
@@ -1682,6 +1685,7 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
while (*work_done < work_to_do) {
/* Check Rx descriptor status */
rx_desc = PCH_GBE_RX_DESC(*rx_ring, i);
+ rmb(); /* prevent any other reads before*/
if (rx_desc->gbec_status == DSC_INIT16)
break;
cleaned = true;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH resend] [IPV6] remove sysctl accept_source_route
From: Eldad Zack @ 2012-05-07 20:52 UTC (permalink / raw)
To: David Miller; +Cc: kuznet, jmorris, yoshfuji, kaber, linux-kernel, netdev
In-Reply-To: <20120506.124151.864202935548493756.davem@davemloft.net>
I'm sorry, I wasn't aware of that.
I will check it from now on.
Eldad
On 6 May 2012 18:41, David Miller <davem@davemloft.net> wrote:
>
> Why are you resending this?
>
> Your patch is sitting in patchwork waiting to be reviewed and applied.
>
> When you needlessly resend a patch it makes more work for me, so do
> not do this. Check the queue at:
>
> http://patchwork.ozlabs.org/project/netdev/list/
>
> first.
^ permalink raw reply
* [PULL net-next] macvtap, vhost and virtio tools updates
From: Michael S. Tsirkin @ 2012-05-07 20:55 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kvm, jasowang, mst
There are mostly bugfixes here.
I hope to merge some more patches by 3.5, in particular
vlan support fixes are waiting for Eric's ack,
and a version of tracepoint patch might be
ready in time, but let's merge what's ready so it's testable.
This includes a ton of zerocopy fixes by Jason -
good stuff but too intrusive for 3.4 and zerocopy is experimental
anyway.
virtio supported delayed interrupt for a while now
so adding support to the virtio tool made sense
Please pull into net-next and merge for 3.5.
Thanks!
MST
The following changes since commit e4ae004b84b315dd4b762e474f97403eac70f76a:
netem: add ECN capability (2012-05-01 09:39:48 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net-next
for you to fetch changes up to c70aa540c7a9f67add11ad3161096fb95233aa2e:
vhost: zerocopy: poll vq in zerocopy callback (2012-05-02 18:22:25 +0300)
----------------------------------------------------------------
Jason Wang (9):
macvtap: zerocopy: fix offset calculation when building skb
macvtap: zerocopy: fix truesize underestimation
macvtap: zerocopy: put page when fail to get all requested user pages
macvtap: zerocopy: set SKBTX_DEV_ZEROCOPY only when skb is built successfully
macvtap: zerocopy: validate vectors before building skb
vhost_net: zerocopy: fix possible NULL pointer dereference of vq->bufs
vhost_net: re-poll only on EAGAIN or ENOBUFS
vhost_net: zerocopy: adding and signalling immediately when fully copied
vhost: zerocopy: poll vq in zerocopy callback
Michael S. Tsirkin (1):
virtio/tools: add delayed interupt mode
drivers/net/macvtap.c | 57 ++++++++++++++++++++++++++++++-------------
drivers/vhost/net.c | 7 ++++-
drivers/vhost/vhost.c | 1 +
tools/virtio/linux/virtio.h | 1 +
tools/virtio/virtio_test.c | 26 ++++++++++++++++---
5 files changed, 69 insertions(+), 23 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/2] vhost: basic tracepoints
From: Michael S. Tsirkin @ 2012-05-07 21:10 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20120410025819.49693.32870.stgit@amd-6168-8-1.englab.nay.redhat.com>
On Tue, Apr 10, 2012 at 10:58:19AM +0800, Jason Wang wrote:
> To help for the performance optimizations and debugging, this patch tracepoints
> for vhost. Pay attention that the tracepoints are only for vhost, net code are
> not touched.
>
> Two kinds of activities were traced: virtio and vhost work.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Thanks for looking into this.
Some questions:
Do we need to prefix traces with vhost_virtio_?
How about a trace for enabling/disabling interrupts?
Trace for a suppressed interrupt?
I think we need a vq # not pointer.
Also need some id for when there are many guests.
Use the vhost thread name (includes owner pid)? It's pid? Both?
Also, traces do add very small overhead when compiled but not
enabled mainly due to increasing register pressure.
Need to test to make sure perf is not hurt.
Some traces are just for debugging so build them on
debug kernel only?
Further, there are many events some are rare
some are common. I think we need some naming scheme
so that really useful and low overhead stuff is easier
to enable ignoring the rarely usefu;/higher overhead traces.
> ---
> drivers/vhost/trace.h | 153 +++++++++++++++++++++++++++++++++++++++++++++++++
> drivers/vhost/vhost.c | 17 +++++
> 2 files changed, 168 insertions(+), 2 deletions(-)
> create mode 100644 drivers/vhost/trace.h
>
> diff --git a/drivers/vhost/trace.h b/drivers/vhost/trace.h
> new file mode 100644
> index 0000000..0423899
> --- /dev/null
> +++ b/drivers/vhost/trace.h
> @@ -0,0 +1,153 @@
> +#if !defined(_TRACE_VHOST_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_VHOST_H
> +
> +#include <linux/tracepoint.h>
> +#include "vhost.h"
> +
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM vhost
> +
> +/*
> + * Tracepoint for updating used flag.
> + */
> +TRACE_EVENT(vhost_virtio_update_used_flags,
> + TP_PROTO(struct vhost_virtqueue *vq),
> + TP_ARGS(vq),
> +
> + TP_STRUCT__entry(
> + __field(struct vhost_virtqueue *, vq)
> + __field(u16, used_flags)
> + ),
> +
> + TP_fast_assign(
> + __entry->vq = vq;
> + __entry->used_flags = vq->used_flags;
> + ),
> +
> + TP_printk("vhost update used flag %x to vq %p notify %s",
> + __entry->used_flags, __entry->vq,
> + (__entry->used_flags & VRING_USED_F_NO_NOTIFY) ?
> + "disabled" : "enabled")
> +);
> +
> +/*
> + * Tracepoint for updating avail event.
> + */
> +TRACE_EVENT(vhost_virtio_update_avail_event,
> + TP_PROTO(struct vhost_virtqueue *vq),
> + TP_ARGS(vq),
> +
> + TP_STRUCT__entry(
> + __field(struct vhost_virtqueue *, vq)
> + __field(u16, avail_idx)
> + ),
> +
> + TP_fast_assign(
> + __entry->vq = vq;
> + __entry->avail_idx = vq->avail_idx;
> + ),
> +
> + TP_printk("vhost update avail idx %u(%u) for vq %p",
> + __entry->avail_idx, __entry->avail_idx %
> + __entry->vq->num, __entry->vq)
> +);
> +
> +/*
> + * Tracepoint for processing descriptor.
> + */
> +TRACE_EVENT(vhost_virtio_get_vq_desc,
> + TP_PROTO(struct vhost_virtqueue *vq, unsigned int index,
> + unsigned out, unsigned int in),
> + TP_ARGS(vq, index, out, in),
> +
> + TP_STRUCT__entry(
> + __field(struct vhost_virtqueue *, vq)
> + __field(unsigned int, head)
> + __field(unsigned int, out)
> + __field(unsigned int, in)
> + ),
> +
> + TP_fast_assign(
> + __entry->vq = vq;
> + __entry->head = index;
> + __entry->out = out;
> + __entry->in = in;
> + ),
> +
> + TP_printk("vhost get vq %p head %u out %u in %u",
> + __entry->vq, __entry->head, __entry->out, __entry->in)
> +
> +);
> +
> +/*
> + * Tracepoint for signal guest.
> + */
> +TRACE_EVENT(vhost_virtio_signal,
> + TP_PROTO(struct vhost_virtqueue *vq),
> + TP_ARGS(vq),
> +
> + TP_STRUCT__entry(
> + __field(struct vhost_virtqueue *, vq)
> + ),
> +
> + TP_fast_assign(
> + __entry->vq = vq;
> + ),
> +
> + TP_printk("vhost signal vq %p", __entry->vq)
> +);
> +
> +DECLARE_EVENT_CLASS(vhost_work_template,
> + TP_PROTO(struct vhost_dev *dev, struct vhost_work *work),
> + TP_ARGS(dev, work),
> +
> + TP_STRUCT__entry(
> + __field(struct vhost_dev *, dev)
> + __field(struct vhost_work *, work)
> + __field(void *, function)
> + ),
> +
> + TP_fast_assign(
> + __entry->dev = dev;
> + __entry->work = work;
> + __entry->function = work->fn;
> + ),
> +
> + TP_printk("%pf for work %p dev %p",
> + __entry->function, __entry->work, __entry->dev)
> +);
> +
> +DEFINE_EVENT(vhost_work_template, vhost_work_queue_wakeup,
> + TP_PROTO(struct vhost_dev *dev, struct vhost_work *work),
> + TP_ARGS(dev, work));
> +
> +DEFINE_EVENT(vhost_work_template, vhost_work_queue_coalesce,
> + TP_PROTO(struct vhost_dev *dev, struct vhost_work *work),
> + TP_ARGS(dev, work));
> +
> +DEFINE_EVENT(vhost_work_template, vhost_poll_start,
> + TP_PROTO(struct vhost_dev *dev, struct vhost_work *work),
> + TP_ARGS(dev, work));
> +
> +DEFINE_EVENT(vhost_work_template, vhost_poll_stop,
> + TP_PROTO(struct vhost_dev *dev, struct vhost_work *work),
> + TP_ARGS(dev, work));
> +
> +DEFINE_EVENT(vhost_work_template, vhost_work_execute_start,
> + TP_PROTO(struct vhost_dev *dev, struct vhost_work *work),
> + TP_ARGS(dev, work));
> +
> +DEFINE_EVENT(vhost_work_template, vhost_work_execute_end,
> + TP_PROTO(struct vhost_dev *dev, struct vhost_work *work),
> + TP_ARGS(dev, work));
> +
> +#endif /* _TRACE_VHOST_H */
> +
> +#undef TRACE_INCLUDE_PATH
> +#define TRACE_INCLUDE_PATH ../../drivers/vhost
> +#undef TRACE_INCLUDE_FILE
> +#define TRACE_INCLUDE_FILE trace
> +
> +/* This part must be outside protection */
> +#include <trace/define_trace.h>
> +
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index c14c42b..23f8d85 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -31,6 +31,8 @@
> #include <linux/if_arp.h>
>
> #include "vhost.h"
> +#define CREATE_TRACE_POINTS
> +#include "trace.h"
>
> enum {
> VHOST_MEMORY_MAX_NREGIONS = 64,
> @@ -50,6 +52,7 @@ static void vhost_poll_func(struct file *file, wait_queue_head_t *wqh,
> poll = container_of(pt, struct vhost_poll, table);
> poll->wqh = wqh;
> add_wait_queue(wqh, &poll->wait);
> + trace_vhost_poll_start(NULL, &poll->work);
> }
>
> static int vhost_poll_wakeup(wait_queue_t *wait, unsigned mode, int sync,
> @@ -101,6 +104,7 @@ void vhost_poll_start(struct vhost_poll *poll, struct file *file)
> void vhost_poll_stop(struct vhost_poll *poll)
> {
> remove_wait_queue(poll->wqh, &poll->wait);
> + trace_vhost_poll_stop(NULL, &poll->work);
> }
>
> static bool vhost_work_seq_done(struct vhost_dev *dev, struct vhost_work *work,
> @@ -147,7 +151,9 @@ static inline void vhost_work_queue(struct vhost_dev *dev,
> list_add_tail(&work->node, &dev->work_list);
> work->queue_seq++;
> wake_up_process(dev->worker);
> - }
> + trace_vhost_work_queue_wakeup(dev, work);
> + } else
> + trace_vhost_work_queue_coalesce(dev, work);
> spin_unlock_irqrestore(&dev->work_lock, flags);
> }
>
> @@ -221,7 +227,9 @@ static int vhost_worker(void *data)
>
> if (work) {
> __set_current_state(TASK_RUNNING);
> + trace_vhost_work_execute_start(dev, work);
> work->fn(work);
> + trace_vhost_work_execute_end(dev, work);
> } else
> schedule();
>
> @@ -1011,6 +1019,7 @@ static int vhost_update_used_flags(struct vhost_virtqueue *vq)
> if (vq->log_ctx)
> eventfd_signal(vq->log_ctx, 1);
> }
> + trace_vhost_virtio_update_used_flags(vq);
> return 0;
> }
>
> @@ -1030,6 +1039,7 @@ static int vhost_update_avail_event(struct vhost_virtqueue *vq, u16 avail_event)
> if (vq->log_ctx)
> eventfd_signal(vq->log_ctx, 1);
> }
> + trace_vhost_virtio_update_avail_event(vq);
> return 0;
> }
>
> @@ -1319,6 +1329,7 @@ int vhost_get_vq_desc(struct vhost_dev *dev, struct vhost_virtqueue *vq,
> /* Assume notifications from guest are disabled at this point,
> * if they aren't we would need to update avail_event index. */
> BUG_ON(!(vq->used_flags & VRING_USED_F_NO_NOTIFY));
> + trace_vhost_virtio_get_vq_desc(vq, head, *out_num, *in_num);
> return head;
> }
>
> @@ -1485,8 +1496,10 @@ static bool vhost_notify(struct vhost_dev *dev, struct vhost_virtqueue *vq)
> void vhost_signal(struct vhost_dev *dev, struct vhost_virtqueue *vq)
> {
> /* Signal the Guest tell them we used something up. */
> - if (vq->call_ctx && vhost_notify(dev, vq))
> + if (vq->call_ctx && vhost_notify(dev, vq)) {
> eventfd_signal(vq->call_ctx, 1);
> + trace_vhost_virtio_signal(vq);
> + }
> }
>
> /* And here's the combo meal deal. Supersize me! */
^ permalink raw reply
* [PATCH] net/bluetooth/bnep/core.c: use constant for ethertype
From: Eldad Zack @ 2012-05-07 22:09 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S. Miller
Cc: linux-bluetooth, netdev, linux-kernel, Eldad Zack
The dot1q ethertype number (0x8100) is embedded in the code, although
it is already defined in included headers.
Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
---
net/bluetooth/bnep/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c
index a779ec7..4fab436 100644
--- a/net/bluetooth/bnep/core.c
+++ b/net/bluetooth/bnep/core.c
@@ -340,7 +340,7 @@ static inline int bnep_rx_frame(struct bnep_session *s, struct sk_buff *skb)
}
/* Strip 802.1p header */
- if (ntohs(s->eh.h_proto) == 0x8100) {
+ if (ntohs(s->eh.h_proto) == ETH_P_8021Q) {
if (!skb_pull(skb, 4))
goto badframe;
s->eh.h_proto = get_unaligned((__be16 *) (skb->data - 2));
--
1.7.10
^ permalink raw reply related
* Re: Netlink for kernel<->user space communication?
From: Stephen Hemminger @ 2012-05-07 22:33 UTC (permalink / raw)
To: Arvid Brodin; +Cc: netdev@vger.kernel.org
In-Reply-To: <4FA817C8.9040204@xdin.com>
On Mon, 7 May 2012 18:43:23 +0000
Arvid Brodin <Arvid.Brodin@xdin.com> wrote:
> On Tue, 24 Apr 2012 16:57:55 -0700
> Stephen Hemminger <shemminger@xxxxxxxxxx> wrote:
> > On Tue, 24 Apr 2012 23:52:34 +0000
> > Arvid Brodin <Arvid.Brodin@xxxxxxxx> wrote:
> >
> >> Hi.
> >>
> >> I'm writing a kernel driver for the HSR protocol, a standard for high availability
> >> networks. I want to send messages from the kernel to user space about broken network
> >> links. I also want user space to be able to ask the kernel about its view of the status of
> >> nodes on the network.
> >>
> >> Netlink seems like a good tool for this. (Is it?)
> >
> > Yes.
> >
> >> But do I use raw netlink? (Described here: http://www.linuxjournal.com/article/7356 - but
> >> this seems a bit out of date, the kernel API description differs from today's kernel
> >> implementation.)
> >
> > No. Your driver probably looks like a device so you should be
> > using rtnetlink messages.
>
> I'm already using rtnetlink messages to add and remove my device, which works fine (see
> e.g. http://www.spinics.net/lists/netdev/msg192817.html - although I didn't think it
> meaningful to include the iproute2 patch here, until the kernel part is ready).
>
> The protocol specifies transmission of "supervision frames" every 2 seconds, e.g. to check
> link integrity. Every such frame should be received from two directions in the ring - if
> only one is received, then there is a link problem.
Why not just manipulate the carrier or operational state (see Documentation/networking/operstate)
and use the existing notification on link changes. If you don't get heartbeat then change
the state of the device to indicate lower device is down with set_operstate(), the necessary
link everts propgate back as netlink events.
> I'd like to notify user space about every such occurence. Is there a rtnetlink message
> type that fits this? The stuff in rtnetlink.h seems to be mostly concerned with specific
> user space commands (there is something called RTNLGRP_NOTIFY but I couldn't find any
> instances of it being used in the kernel, nor any documentation).
>
I am trying to steer you to use existing API's because then existing programs and
infrastructure can deal with the new device type.
^ permalink raw reply
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