* [PATCHv3 net-next 2/4] caif: Add support for CAIF over CDC NCM USB interface
From: Sjur Brændeland @ 2011-12-04 21:22 UTC (permalink / raw)
To: netdev, David Miller; +Cc: Alexey Orishko, Eric Dumazet, Sjur Brændeland
In-Reply-To: <1323033775-3496-1-git-send-email-sjur.brandeland@stericsson.com>
NCM 1.0 does not support anything but Ethernet framing, hence
CAIF payload will be put into Ethernet frames.
Discovery is based on fixed USB vendor 0x04cc (ST-Ericsson),
product-id 0x230f (NCM). In this variant only CAIF payload is sent over
the NCM interface.
The CAIF stack (cfusbl.c) will when USB interface register first check if
we got a CDC NCM USB interface with the right VID, PID.
It will then read the device's Ethernet address and create a 'template'
Ethernet TX header, using a broadcast address as the destination address,
and EthType 0x88b5 (802.1 Local Experimental - vendor specific).
A protocol handler for 0x88b5 is setup for reception of CAIF frames from
the CDC NCM USB interface.
Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
---
Hi Dave,
>Please make this feature a tristate and make the init and exit
>routines executed via the normal modula_init()/module_exit()
>mechanisms.
>That way you don't need that dopey header file to export the
>init and exit routines, and you don't need to ifdef crap up the
>code CAIF code to invoke them.
Done.
Changes from V2:
o As suggested: Killed of header file and ifdefs, and made it tristate
o Renamed module name to caif_usb
o Exported a few functions
o Had to handle refcnt for caif_usb module when USB NCM device registers
and unregisters.
Regards,
Sjur
net/caif/Kconfig | 11 +++
net/caif/Makefile | 1 +
net/caif/caif_dev.c | 1 +
net/caif/caif_usb.c | 208 +++++++++++++++++++++++++++++++++++++++++++++++
net/caif/cfpkt_skbuff.c | 12 +--
5 files changed, 224 insertions(+), 9 deletions(-)
create mode 100644 net/caif/caif_usb.c
diff --git a/net/caif/Kconfig b/net/caif/Kconfig
index 529750d..936361e 100644
--- a/net/caif/Kconfig
+++ b/net/caif/Kconfig
@@ -40,3 +40,14 @@ config CAIF_NETDEV
If you select to build it as a built-in then the main CAIF device must
also be a built-in.
If unsure say Y.
+
+config CAIF_USB
+ tristate "CAIF USB support"
+ depends on CAIF
+ default n
+ ---help---
+ Say Y if you are using CAIF over USB CDC NCM.
+ This can be either built-in or a loadable module,
+ If you select to build it as a built-in then the main CAIF device must
+ also be a built-in.
+ If unsure say N.
diff --git a/net/caif/Makefile b/net/caif/Makefile
index ebcd4e7..cc2b511 100644
--- a/net/caif/Makefile
+++ b/net/caif/Makefile
@@ -10,5 +10,6 @@ caif-y := caif_dev.o \
obj-$(CONFIG_CAIF) += caif.o
obj-$(CONFIG_CAIF_NETDEV) += chnl_net.o
obj-$(CONFIG_CAIF) += caif_socket.o
+obj-$(CONFIG_CAIF_USB) += caif_usb.o
export-y := caif.o
diff --git a/net/caif/caif_dev.c b/net/caif/caif_dev.c
index f7e8c70..6acec19 100644
--- a/net/caif/caif_dev.c
+++ b/net/caif/caif_dev.c
@@ -262,6 +262,7 @@ void caif_enroll_dev(struct net_device *dev, struct caif_dev_common *caifdev,
if (rcv_func)
*rcv_func = receive;
}
+EXPORT_SYMBOL(caif_enroll_dev);
/* notify Caif of device events */
static int caif_device_notify(struct notifier_block *me, unsigned long what,
diff --git a/net/caif/caif_usb.c b/net/caif/caif_usb.c
new file mode 100644
index 0000000..f5db57c
--- /dev/null
+++ b/net/caif/caif_usb.c
@@ -0,0 +1,208 @@
+/*
+ * CAIF USB handler
+ * Copyright (C) ST-Ericsson AB 2011
+ * Author: Sjur Brendeland/sjur.brandeland@stericsson.com
+ * License terms: GNU General Public License (GPL) version 2
+ *
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ":%s(): " fmt, __func__
+
+#include <linux/module.h>
+#include <linux/netdevice.h>
+#include <linux/slab.h>
+#include <linux/netdevice.h>
+#include <linux/mii.h>
+#include <linux/usb.h>
+#include <linux/usb/usbnet.h>
+#include <net/netns/generic.h>
+#include <net/caif/caif_dev.h>
+#include <net/caif/caif_layer.h>
+#include <net/caif/cfpkt.h>
+#include <net/caif/cfcnfg.h>
+
+MODULE_LICENSE("GPL");
+
+#define CFUSB_PAD_DESCR_SZ 1 /* Alignment descriptor length */
+#define CFUSB_ALIGNMENT 4 /* Number of bytes to align. */
+#define CFUSB_MAX_HEADLEN (CFUSB_PAD_DESCR_SZ + CFUSB_ALIGNMENT-1)
+#define STE_USB_VID 0x04cc /* USB Product ID for ST-Ericsson */
+#define STE_USB_PID_CAIF 0x2306 /* Product id for CAIF Modems */
+
+struct cfusbl {
+ struct cflayer layer;
+ u8 tx_eth_hdr[ETH_HLEN];
+};
+
+static bool pack_added;
+
+static int cfusbl_receive(struct cflayer *layr, struct cfpkt *pkt)
+{
+ u8 hpad;
+
+ /* Remove padding. */
+ cfpkt_extr_head(pkt, &hpad, 1);
+ cfpkt_extr_head(pkt, NULL, hpad);
+ return layr->up->receive(layr->up, pkt);
+}
+
+static int cfusbl_transmit(struct cflayer *layr, struct cfpkt *pkt)
+{
+ struct caif_payload_info *info;
+ u8 hpad;
+ u8 zeros[CFUSB_ALIGNMENT];
+ struct sk_buff *skb;
+ struct cfusbl *usbl = container_of(layr, struct cfusbl, layer);
+
+ skb = cfpkt_tonative(pkt);
+
+ skb_reset_network_header(skb);
+ skb->protocol = htons(ETH_P_IP);
+
+ info = cfpkt_info(pkt);
+ hpad = (info->hdr_len + CFUSB_PAD_DESCR_SZ) & (CFUSB_ALIGNMENT - 1);
+
+ if (skb_headroom(skb) < ETH_HLEN + CFUSB_PAD_DESCR_SZ + hpad) {
+ pr_warn("Headroom to small\n");
+ kfree_skb(skb);
+ return -EIO;
+ }
+ memset(zeros, 0, hpad);
+
+ cfpkt_add_head(pkt, zeros, hpad);
+ cfpkt_add_head(pkt, &hpad, 1);
+ cfpkt_add_head(pkt, usbl->tx_eth_hdr, sizeof(usbl->tx_eth_hdr));
+ return layr->dn->transmit(layr->dn, pkt);
+}
+
+static void cfusbl_ctrlcmd(struct cflayer *layr, enum caif_ctrlcmd ctrl,
+ int phyid)
+{
+ if (layr->up && layr->up->ctrlcmd)
+ layr->up->ctrlcmd(layr->up, ctrl, layr->id);
+}
+
+struct cflayer *cfusbl_create(int phyid, u8 ethaddr[ETH_ALEN],
+ u8 braddr[ETH_ALEN])
+{
+ struct cfusbl *this = kmalloc(sizeof(struct cfusbl), GFP_ATOMIC);
+
+ if (!this) {
+ pr_warn("Out of memory\n");
+ return NULL;
+ }
+ caif_assert(offsetof(struct cfusbl, layer) == 0);
+
+ memset(this, 0, sizeof(struct cflayer));
+ this->layer.receive = cfusbl_receive;
+ this->layer.transmit = cfusbl_transmit;
+ this->layer.ctrlcmd = cfusbl_ctrlcmd;
+ snprintf(this->layer.name, CAIF_LAYER_NAME_SZ, "usb%d", phyid);
+ this->layer.id = phyid;
+
+ /*
+ * Construct TX ethernet header:
+ * 0-5 destination address
+ * 5-11 source address
+ * 12-13 protocol type
+ */
+ memcpy(&this->tx_eth_hdr[ETH_ALEN], braddr, ETH_ALEN);
+ memcpy(&this->tx_eth_hdr[ETH_ALEN], ethaddr, ETH_ALEN);
+ this->tx_eth_hdr[12] = cpu_to_be16(ETH_P_802_EX1) & 0xff;
+ this->tx_eth_hdr[13] = (cpu_to_be16(ETH_P_802_EX1) >> 8) & 0xff;
+ pr_debug("caif ethernet TX-header dst:%pM src:%pM type:%02x%02x\n",
+ this->tx_eth_hdr, this->tx_eth_hdr + ETH_ALEN,
+ this->tx_eth_hdr[12], this->tx_eth_hdr[13]);
+
+ return (struct cflayer *) this;
+}
+
+static struct packet_type caif_usb_type __read_mostly = {
+ .type = cpu_to_be16(ETH_P_802_EX1),
+};
+
+static int cfusbl_device_notify(struct notifier_block *me, unsigned long what,
+ void *arg)
+{
+ struct net_device *dev = arg;
+ struct caif_dev_common common;
+ struct cflayer *layer, *link_support;
+ struct usbnet *usbnet = netdev_priv(dev);
+ struct usb_device *usbdev = usbnet->udev;
+ struct ethtool_drvinfo drvinfo;
+
+ /*
+ * Quirks: High-jack ethtool to find if we have a NCM device,
+ * and find it's VID/PID.
+ */
+ if (dev->ethtool_ops == NULL || dev->ethtool_ops->get_drvinfo == NULL)
+ return 0;
+
+ dev->ethtool_ops->get_drvinfo(dev, &drvinfo);
+ if (strncmp(drvinfo.driver, "cdc_ncm", 7) != 0)
+ return 0;
+
+ pr_debug("USB CDC NCM device VID:0x%4x PID:0x%4x\n",
+ le16_to_cpu(usbdev->descriptor.idVendor),
+ le16_to_cpu(usbdev->descriptor.idProduct));
+
+ /* Check for VID/PID that supports CAIF */
+ if (!(le16_to_cpu(usbdev->descriptor.idVendor) == STE_USB_VID &&
+ le16_to_cpu(usbdev->descriptor.idProduct) == STE_USB_PID_CAIF))
+ return 0;
+
+ if (what == NETDEV_UNREGISTER)
+ module_put(THIS_MODULE);
+
+ if (what != NETDEV_REGISTER)
+ return 0;
+
+ __module_get(THIS_MODULE);
+
+ memset(&common, 0, sizeof(common));
+ common.use_frag = false;
+ common.use_fcs = false;
+ common.use_stx = false;
+ common.link_select = CAIF_LINK_HIGH_BANDW;
+ common.flowctrl = NULL;
+
+ link_support = cfusbl_create(dev->ifindex, dev->dev_addr,
+ dev->broadcast);
+
+ if (!link_support)
+ return -ENOMEM;
+
+ if (dev->num_tx_queues > 1)
+ pr_warn("USB device uses more than one tx queue\n");
+
+ caif_enroll_dev(dev, &common, link_support, CFUSB_MAX_HEADLEN,
+ &layer, &caif_usb_type.func);
+ if (!pack_added)
+ dev_add_pack(&caif_usb_type);
+ pack_added = 1;
+
+ strncpy(layer->name, dev->name,
+ sizeof(layer->name) - 1);
+ layer->name[sizeof(layer->name) - 1] = 0;
+
+ return 0;
+}
+
+static struct notifier_block caif_device_notifier = {
+ .notifier_call = cfusbl_device_notify,
+ .priority = 0,
+};
+
+static int __init cfusbl_init(void)
+{
+ return register_netdevice_notifier(&caif_device_notifier);
+}
+
+static void __exit cfusbl_exit(void)
+{
+ unregister_netdevice_notifier(&caif_device_notifier);
+ dev_remove_pack(&caif_usb_type);
+}
+
+module_init(cfusbl_init);
+module_exit(cfusbl_exit);
diff --git a/net/caif/cfpkt_skbuff.c b/net/caif/cfpkt_skbuff.c
index de53907..e335ba8 100644
--- a/net/caif/cfpkt_skbuff.c
+++ b/net/caif/cfpkt_skbuff.c
@@ -63,7 +63,6 @@ static inline struct cfpkt *skb_to_pkt(struct sk_buff *skb)
return (struct cfpkt *) skb;
}
-
struct cfpkt *cfpkt_fromnative(enum caif_direction dir, void *nativepkt)
{
struct cfpkt *pkt = skb_to_pkt(nativepkt);
@@ -105,14 +104,12 @@ void cfpkt_destroy(struct cfpkt *pkt)
kfree_skb(skb);
}
-
inline bool cfpkt_more(struct cfpkt *pkt)
{
struct sk_buff *skb = pkt_to_skb(pkt);
return skb->len > 0;
}
-
int cfpkt_peek_head(struct cfpkt *pkt, void *data, u16 len)
{
struct sk_buff *skb = pkt_to_skb(pkt);
@@ -148,6 +145,7 @@ int cfpkt_extr_head(struct cfpkt *pkt, void *data, u16 len)
memcpy(data, from, len);
return 0;
}
+EXPORT_SYMBOL(cfpkt_extr_head);
int cfpkt_extr_trail(struct cfpkt *pkt, void *dta, u16 len)
{
@@ -171,13 +169,11 @@ int cfpkt_extr_trail(struct cfpkt *pkt, void *dta, u16 len)
return 0;
}
-
int cfpkt_pad_trail(struct cfpkt *pkt, u16 len)
{
return cfpkt_add_body(pkt, NULL, len);
}
-
int cfpkt_add_body(struct cfpkt *pkt, const void *data, u16 len)
{
struct sk_buff *skb = pkt_to_skb(pkt);
@@ -256,21 +252,19 @@ int cfpkt_add_head(struct cfpkt *pkt, const void *data2, u16 len)
memcpy(to, data, len);
return 0;
}
-
+EXPORT_SYMBOL(cfpkt_add_head);
inline int cfpkt_add_trail(struct cfpkt *pkt, const void *data, u16 len)
{
return cfpkt_add_body(pkt, data, len);
}
-
inline u16 cfpkt_getlen(struct cfpkt *pkt)
{
struct sk_buff *skb = pkt_to_skb(pkt);
return skb->len;
}
-
inline u16 cfpkt_iterate(struct cfpkt *pkt,
u16 (*iter_func)(u16, void *, u16),
u16 data)
@@ -288,7 +282,6 @@ inline u16 cfpkt_iterate(struct cfpkt *pkt,
return iter_func(data, pkt->skb.data, cfpkt_getlen(pkt));
}
-
int cfpkt_setlen(struct cfpkt *pkt, u16 len)
{
struct sk_buff *skb = pkt_to_skb(pkt);
@@ -400,3 +393,4 @@ struct caif_payload_info *cfpkt_info(struct cfpkt *pkt)
{
return (struct caif_payload_info *)&pkt_to_skb(pkt)->cb;
}
+EXPORT_SYMBOL(cfpkt_info);
--
1.7.0.4
^ permalink raw reply related
* [PATCHv3 net-next 1/4] if_ether.h: Add IEEE 802.1 Local Experimental Ethertype 1.
From: Sjur Brændeland @ 2011-12-04 21:22 UTC (permalink / raw)
To: netdev, David Miller; +Cc: Alexey Orishko, Eric Dumazet, Sjur Brændeland
Add EthType 0x88b5.
This Ethertype value is available for public use for prototype and
vendor-specific protocol development,as defined in Amendment 802a
to IEEE Std 802.
Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
---
include/linux/if_ether.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h
index e473003..56d907a 100644
--- a/include/linux/if_ether.h
+++ b/include/linux/if_ether.h
@@ -79,6 +79,7 @@
#define ETH_P_PAE 0x888E /* Port Access Entity (IEEE 802.1X) */
#define ETH_P_AOE 0x88A2 /* ATA over Ethernet */
#define ETH_P_8021AD 0x88A8 /* 802.1ad Service VLAN */
+#define ETH_P_802_EX1 0x88B5 /* 802.1 Local Experimental 1. */
#define ETH_P_TIPC 0x88CA /* TIPC */
#define ETH_P_8021AH 0x88E7 /* 802.1ah Backbone Service Tag */
#define ETH_P_1588 0x88F7 /* IEEE 1588 Timesync */
--
1.7.0.4
^ permalink raw reply related
* Re: [Linux-decnet-user] Proposed removal of DECnet support (was:Re: [BUG] 3.2-rc2:BUG kmalloc-8: Redzone overwritten)
From: Philipp Schafft @ 2011-12-04 19:54 UTC (permalink / raw)
To: mike.gair
Cc: Steven Whitehouse, Chrissie Caulfield, Christoph Lameter,
David Miller, Eric Dumazet, Sasha Levin, Linux-DECnet user,
linux-kernel, linux-mm, Matt Mackall, netdev, Pekka Enberg,
RoarAudio
In-Reply-To: <OF6A1EB29A.D9A6FBAC-ON8025795A.00311C05-8025795A.0032A610@LocalDomain>
[-- Attachment #1: Type: text/plain, Size: 689 bytes --]
reflum,
On Fri, 2011-12-02 at 09:14 +0000, mike.gair@tatasteel.com wrote:
> I suspect I'm not up to the job,
>
> - definitely not got an in-depth knowledge of the core Linux
> networking stack
> or the DECnet specs,
> Have limited, but growing experience of C, (mainly work in coral66)
I'm willing to offer you help with C and the protocol stuff. I'm the
current most active developer of the userland part.
> But I'll have a look at code/documentation
> & see if I understand any of it.
Ok. If you are still interested let me know if I can help you with the
above. Maybe Steven can give you some pointers for the kernel stuff.
>
--
Philipp.
(Rah of PH2)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]
^ permalink raw reply
* Re: [Linux-decnet-user] Proposed removal of DECnet support (was:Re: [BUG] 3.2-rc2:BUG kmalloc-8: Redzone overwritten)
From: Philipp Schafft @ 2011-12-04 19:50 UTC (permalink / raw)
To: Steven Whitehouse
Cc: mike.gair, Chrissie Caulfield, Christoph Lameter, David Miller,
Eric Dumazet, Sasha Levin, Linux-DECnet user, linux-kernel,
linux-mm, Matt Mackall, netdev, Pekka Enberg, RoarAudio
In-Reply-To: <1322664737.2755.17.camel@menhir>
[-- Attachment #1: Type: text/plain, Size: 3008 bytes --]
reflum,
On Wed, 2011-11-30 at 14:52 +0000, Steven Whitehouse wrote:
> On Wed, 2011-11-30 at 13:52 +0000, mike.gair@tatasteel.com wrote:
> > In theory i'd be interested in maintaining it,
> > but i'm not sure what amount of work is involved,
> > have no experience of kernel, or where to start.
> >
> > Any ideas?
> >
> >
> So the issue is basically that due to there being nobody currently
> maintaining the DECnet stack, it puts a burden on the core network
> maintainers when they make cross-protocol changes, as they have to
> figure out what impact the changes are likely to have on the DECnet
> stack. So its an extra barrier to making cross-protocol code changes.
>
> If there was an active maintainer who could be a source of knowledge
> (and the odd patch to help out making those changes) then this issue
> would largely go away.
*nods*
> The most important duty of the maintainer is just to watch whats going
> on in the core networking development and to contribute the DECnet part
> of that. So it would be most likely be more a reviewing of patches and
> providing advice role, than one of writing patches (though it could be
> that too) and ensuring that the code continues to function correctly by
> testing it from time to time.
>
> The ideal maintainer would have an in-depth knowledge of the core Linux
> networking stack (socket layer, dst and neigh code), the DECnet specs
> and have a good knowledge of C.
I guess I would fit mostly but I have no idea of the kernel internal
stuff. Also I'm a bit short on time.
> Bearing in mind the low patch volume (almost zero, except for core
> stuff), it would probably be one of the subsystems with the least amount
> of work to do in maintaining it. So in some ways, a good intro for a new
> maintainer.
Jup. This is very true. I hope we will find a new maintainer because of
exactly this point. Maybe somebody like Mike Gair.
> I do try and keep an eye on what get submitted to the DECnet code and
> I'll continue to do that while it is still in the kernel. However, it is
> now quite a long time since I last did any substantial work in the
> networking area and things have moved on a fair bit in the mean time. I
> don't have a lot of time to review DECnet patches these days and no way
> to actually test any contributions against a real DECnet implementation.
I'm glad you are still interested. I'm always happy when I see mails
from you at the DECnet for Linux list.
> So I'll provide what help I can to anybody who wants to take the role
> on, within those limitations. I'm also happy to answer questions about
> why things were done in a particular way, for example.
>
> It is good to know that people are still using the Linux DECnet code
> too. It has lived far beyond the time when I'd envisioned it still being
> useful :-)
There are still some people interested in it. Btw. on Debian popcon
counts 5356 users.
--
Philipp.
(Rah of PH2)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] can: cc770: add legacy ISA bus driver for the CC770 and AN82527
From: Wolfgang Grandegger @ 2011-12-04 18:56 UTC (permalink / raw)
To: info
Cc: Oliver Hartkopp, netdev, linux-can, socketcan-users, IreneV,
Stanislav Yelenskiy
In-Reply-To: <4EDBC05D.8070109@essax.com>
Hi Wolfgang,
On 12/04/2011 07:47 PM, Wolfgang Zarre wrote:
> Hello Wolfgang,
...
>> Wolfgang, I just sent out v4. Any chance to give this patch a try? It
>> would be best to use a recent kernel version but I could also adapt the
>> patch to your kernel version, 2.6.39, I think!?
>
> Sorry for my delayed reply, but wasn't earlier possible.
> Yes, of course, as long as I have the hardware available I can do some
> tests, even
> on a recent kernel due the fact having the project so far completed,
> just another
> test run on the 9th of December.
>
> Due the flood of emails I lost now track which version You would be
> interested in
> and maybe also which kernel version, so, please let me know and maybe
> were I may
> download the patches.
Well, yes, I was spinning too fast but the patches have been accepted in
the meantime (actually v6 made it). So you just need to clone the most
recent version of Dave's net-next tree.
>> As you are using a CC770 chip, I'm especially interested in the relevant
>> kernel log (dmesg) and "ip -d -s link show".
>
> Should be not a problem at all.
Great, thanks.
Wolfgang.
^ permalink raw reply
* Re: [PATCH net-next] tcp: tcp_sendmsg() page recycling
From: Joe Perches @ 2011-12-04 18:54 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: Eric Dumazet, netdev, David Miller
In-Reply-To: <4EDBBB86.8050406@gmail.com>
On Sun, 2011-12-04 at 19:27 +0100, Nicolas de Pesloüan wrote:
> Well, those two fragments don't look equivalent to the original one, unless TCP_OFF(sk) happens to
> be 0 before the test. But if this is true, then the whole thing seems useless. Do I miss something?
Nope, you're completely correct. It's just me not typing correctly.
^ permalink raw reply
* Re: [PATCH] tcp: take care of misalignments
From: Eric Dumazet @ 2011-12-04 18:51 UTC (permalink / raw)
To: David Miller; +Cc: subramanian.vijay, therbert, netdev
In-Reply-To: <20111204.132126.654109006321344175.davem@davemloft.net>
Le dimanche 04 décembre 2011 à 13:21 -0500, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sun, 04 Dec 2011 08:39:53 +0100
>
> > [PATCH] tcp: take care of misalignments
> >
> > We discovered that TCP stack could retransmit misaligned skbs if a
> > malicious peer acknowledged sub MSS frame. This currently can happen
> > only if output interface is non SG enabled : If SG is enabled, tcp
> > builds headless skbs (all payload is included in fragments), so the tcp
> > trimming process only removes parts of skb fragments, header stay
> > aligned.
> >
> > Some arches cant handle misalignments, so force a head reallocation and
> > shrink headroom to MAX_TCP_HEADER.
> >
> > Dont care about misaligments on x86 and PPC (or other arches setting
> > NET_IP_ALIGN to 0)
> >
> > This patch introduces __pskb_copy() which can specify the headroom of
> > new head, and pskb_copy() becomes a wrapper on top of __pskb_copy()
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Looks good, applied.
Thanks !
Here a respin of previous patch then ?
[PATCH net-next] tcp: fix tcp_trim_head()
commit f07d960df3 (tcp: avoid frag allocation for small frames)
breaked assumption in tcp stack that skb is either linear (skb->data_len
== 0), or fully fragged (skb->data_len == skb->len)
tcp_trim_head() made this assumption, we must fix it.
Thanks to Vijay for providing a very detailed explanation.
Reported-by: Vijay Subramanian <subramanian.vijay@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/tcp_output.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 50788d6..cf30680 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1093,6 +1093,13 @@ static void __pskb_trim_head(struct sk_buff *skb, int len)
{
int i, k, eat;
+ eat = min_t(int, len, skb_headlen(skb));
+ if (eat) {
+ __skb_pull(skb, eat);
+ len -= eat;
+ if (!len)
+ return;
+ }
eat = len;
k = 0;
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
@@ -1124,11 +1131,7 @@ int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
if (skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
return -ENOMEM;
- /* If len == headlen, we avoid __skb_pull to preserve alignment. */
- if (unlikely(len < skb_headlen(skb)))
- __skb_pull(skb, len);
- else
- __pskb_trim_head(skb, len - skb_headlen(skb));
+ __pskb_trim_head(skb, len);
TCP_SKB_CB(skb)->seq += len;
skb->ip_summed = CHECKSUM_PARTIAL;
^ permalink raw reply related
* Re: [PATCH net-next v2 2/4] can: cc770: add legacy ISA bus driver for the CC770 and AN82527
From: Wolfgang Zarre @ 2011-12-04 18:47 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Oliver Hartkopp, linux-can-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w
In-Reply-To: <4ED4A2EC.40103-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Hello Wolfgang,
> On 11/28/2011 05:06 PM, Oliver Hartkopp wrote:
>>
>>>> ... using a reasonable default for bcr of 0x40. But you may need to
>>>> provide better values for cir, bcr and cor.
>>>>
>>>
>>> OMG, sorry that I was bothering You but You are absolutely right and with Your
>>> statement You brought be back on track and You made my day. Thank You !!!!!!
>>>
>>> I just took the values for cpu and bus I was using in my lincan driver and funny
>>> enough now it's working absolutely perfect.
>>>
>>> Module: modprobe cc770_isa irq=0xa port=0x384 indirect=1 cir=0x61 bcr=0x4A
>>>
>>> Was just sending 50000 telegrams, perfect and no problem at all.
>>>
>>> Thanks a lot again!!!!
>>>
>>
>>
>> This looks like a Tested-by :-)
>
> Wolfgang, I just sent out v4. Any chance to give this patch a try? It
> would be best to use a recent kernel version but I could also adapt the
> patch to your kernel version, 2.6.39, I think!?
Sorry for my delayed reply, but wasn't earlier possible.
Yes, of course, as long as I have the hardware available I can do some tests, even
on a recent kernel due the fact having the project so far completed, just another
test run on the 9th of December.
Due the flood of emails I lost now track which version You would be interested in
and maybe also which kernel version, so, please let me know and maybe were I may
download the patches.
>
> As you are using a CC770 chip, I'm especially interested in the relevant
> kernel log (dmesg) and "ip -d -s link show".
Should be not a problem at all.
>
> Thanks,
>
> Wolfgang.
Wolfgang
^ permalink raw reply
* Re: [PATCH net-next] tcp: tcp_sendmsg() page recycling
From: Nicolas de Pesloüan @ 2011-12-04 18:27 UTC (permalink / raw)
To: Joe Perches; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <1323019253.1785.7.camel@joe2Laptop>
Le 04/12/2011 18:20, Joe Perches a écrit :
> On Sun, 2011-12-04 at 18:05 +0100, Eric Dumazet wrote:
>> If our TCP_PAGE(sk) is not shared (page_count() == 1), we can set page
>> offset to 0.
> []
>> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> []
>> @@ -1009,7 +1009,12 @@ new_segment:
>> int merge = 0;
>> int i = skb_shinfo(skb)->nr_frags;
>> struct page *page = TCP_PAGE(sk);
>> - int off = TCP_OFF(sk);
>> + int off;
>> +
>> + if (page&& page_count(page) == 1)
>> + TCP_OFF(sk) = 0;
>> +
>> + off = TCP_OFF(sk);
>
> This might be clearer and take one less indirection as
>
> if (page&& page_count(page) == 1) {
> TCP_OFF(sk) = 0;
> off = 0;
> } else {
> off = 0;
> }
>
> or maybe
>
> if (page&& page_count(page) == 1)
> off = TCP_OFF(sk) = 0;
> else
> off = 0;
Well, those two fragments don't look equivalent to the original one, unless TCP_OFF(sk) happens to
be 0 before the test. But if this is true, then the whole thing seems useless. Do I miss something?
For as far as I understand, the following should be equivalent to Eric's original, but I don't
consider it better than the original.
if (page&& page_count(page) == 1)
off = TCP_OFF(sk) = 0;
else
off = TCP_OFF(sk);
Nicolas.
^ permalink raw reply
* Re: [PATCH 2/2] unix: Add /proc/net/unix_peers file
From: David Miller @ 2011-12-04 18:25 UTC (permalink / raw)
To: xemul; +Cc: netdev, eric.dumazet
In-Reply-To: <4ED7BC6E.3040600@parallels.com>
From: Pavel Emelyanov <xemul@parallels.com>
Date: Thu, 01 Dec 2011 21:42:06 +0400
> Currently it's not possible to find out what processes are connected
> to each other via a unix socket. In the proposed proc file a socket
> inode number and its peer inode number are shown. With these two at
> hands it's possible to determine the unix connections endpoints.
>
> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
I'm basically against new networking procfs based information
retrieval mechanisms.
Please extend the netlink socket dumping so that it works with
AF_UNIX sockets and subsequently added the necessary netlink
attribute to provide the peer value.
I plan to stand pretty firm on this, so you may want to save your
effort and use said effort to implement this properly.
Thanks.
^ permalink raw reply
* Re: [PATCH] net, fixed phy: make BUSID configurable
From: David Miller @ 2011-12-04 18:23 UTC (permalink / raw)
To: hs; +Cc: netdev, vbordug, akpm, jeff, wd
In-Reply-To: <1322991444-20626-1-git-send-email-hs@denx.de>
From: Heiko Schocher <hs@denx.de>
Date: Sun, 4 Dec 2011 10:37:24 +0100
> Signed-off-by: Heiko Schocher <hs@denx.de>
Give me a break.
You can't submit a change like this with essentially an
empty commit message.
Why in the world does this ever need to be configurable?
Are there alternative (and much better) ways to deal with
whatever problem this patch solves?
You've presented no information about why you need to make this
change, and more importantly why no viable alternatives exist
to solve your problem.
^ permalink raw reply
* Re: [PATCH net-next] tcp: tcp_sendmsg() page recycling
From: David Miller @ 2011-12-04 18:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1323018317.2762.143.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 04 Dec 2011 18:05:17 +0100
> If our TCP_PAGE(sk) is not shared (page_count() == 1), we can set page
> offset to 0.
>
> This permits better filling of the pages on small to medium tcp writes.
>
> "tbench 16" results on my dev server (2x4x2 machine) :
>
> Before : 3072 MB/s
> After : 3146 MB/s (2.4 % gain)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tcp: take care of misalignments
From: David Miller @ 2011-12-04 18:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: subramanian.vijay, therbert, netdev
In-Reply-To: <1322984393.2762.134.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 04 Dec 2011 08:39:53 +0100
> [PATCH] tcp: take care of misalignments
>
> We discovered that TCP stack could retransmit misaligned skbs if a
> malicious peer acknowledged sub MSS frame. This currently can happen
> only if output interface is non SG enabled : If SG is enabled, tcp
> builds headless skbs (all payload is included in fragments), so the tcp
> trimming process only removes parts of skb fragments, header stay
> aligned.
>
> Some arches cant handle misalignments, so force a head reallocation and
> shrink headroom to MAX_TCP_HEADER.
>
> Dont care about misaligments on x86 and PPC (or other arches setting
> NET_IP_ALIGN to 0)
>
> This patch introduces __pskb_copy() which can specify the headroom of
> new head, and pskb_copy() becomes a wrapper on top of __pskb_copy()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Looks good, applied.
^ permalink raw reply
* Re: [PATCHv2 net-next 2/4] caif: Add support for CAIF over CDC NCM USB interface
From: David Miller @ 2011-12-04 18:18 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, alexey.orishko, eric.dumazet
In-Reply-To: <1322993450-8802-3-git-send-email-sjur.brandeland@stericsson.com>
From: Sjur Brændeland <sjur.brandeland@stericsson.com>
Date: Sun, 4 Dec 2011 11:10:48 +0100
> NCM 1.0 does not support anything but Ethernet framing, hence
> CAIF payload will be put into Ethernet frames.
>
> Discovery is based on fixed USB vendor 0x04cc (ST-Ericsson),
> product-id 0x230f (NCM). In this variant only CAIF payload is sent over
> the NCM interface.
>
> The CAIF stack (cfusbl.c) will when USB interface register first check if
> we got a CDC NCM USB interface with the right VID, PID.
> It will then read the device's Ethernet address and create a 'template'
> Ethernet TX header, using a broadcast address as the destination address,
> and EthType 0x88b5 (802.1 Local Experimental - vendor specific).
>
> A protocol handler for 0x88b5 is setup for reception of CAIF frames from
> the CDC NCM USB interface.
>
> Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Please make this feature a tristate and make the init and exit
routines executed via the normal modula_init()/module_exit()
mechanisms.
That way you don't need that dopey header file to export the
init and exit routines, and you don't need to ifdef crap up the
code CAIF code to invoke them.
^ permalink raw reply
* Re: [PATCH net-next] tcp: tcp_sendmsg() page recycling
From: David Miller @ 2011-12-04 18:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1323020212.2762.147.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 04 Dec 2011 18:36:52 +0100
> Definitely worth the pain, isnt it ?
As long as such gains aren't lost in the noise when talking over
real devices.
I'm not a big fan of tbench over loopback numbers, frankly :-)
^ permalink raw reply
* Re: [PATCH net-next] tcp: tcp_sendmsg() page recycling
From: Eric Dumazet @ 2011-12-04 17:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1323018317.2762.143.camel@edumazet-laptop>
Le dimanche 04 décembre 2011 à 18:05 +0100, Eric Dumazet a écrit :
> If our TCP_PAGE(sk) is not shared (page_count() == 1), we can set page
> offset to 0.
>
> This permits better filling of the pages on small to medium tcp writes.
>
> "tbench 16" results on my dev server (2x4x2 machine) :
>
> Before : 3072 MB/s
> After : 3146 MB/s (2.4 % gain)
By the way current linux tree on the same machine gets 2957 MB/s
So the combination of select_size() patch and this one gives
a 6.4 % gain.
Definitely worth the pain, isnt it ?
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Jerome Glisse @ 2011-12-04 17:32 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Dave Airlie, Christoph Lameter, Alex, Shi, Eric Dumazet,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel,
Pekka Enberg, linux-mm@kvack.org, Matt Mackall, tj, Alex Deucher
In-Reply-To: <20111204010200.GA1530@x4.trippels.de>
On Sat, Dec 3, 2011 at 8:02 PM, Markus Trippelsdorf
<markus@trippelsdorf.de> wrote:
> On 2011.12.03 at 14:31 -0500, Jerome Glisse wrote:
>> On Sat, Dec 3, 2011 at 7:29 AM, Markus Trippelsdorf
>> <markus@trippelsdorf.de> wrote:
>> > On 2011.12.03 at 12:20 +0000, Dave Airlie wrote:
>> >> >> > > > > FIX idr_layer_cache: Marking all objects used
>> >> >> > > >
>> >> >> > > > Yesterday I couldn't reproduce the issue at all. But today I've hit
>> >> >> > > > exactly the same spot again. (CCing the drm list)
>> >>
>> >> If I had to guess it looks like 0 is getting written back to some
>> >> random page by the GPU maybe, it could be that the GPU is in some half
>> >> setup state at boot or on a reboot does it happen from a cold boot or
>> >> just warm boot or kexec?
>> >
>> > Only happened with kexec thus far. Cold boot seems to be fine.
>> >
>> > --
>> > Markus
>>
>> Can you add radeon.no_wb=1 to your kexec kernel paramater an see if
>> you can reproduce.
>
> No, I cannot reproduce the issue with radeon.no_wb=1. (I write this
> after 700 successful kexec iterations...)
>
Ok so it's GPU writeback will do a patch on monday.
Cheers,
Jerome
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net-next] tcp: tcp_sendmsg() page recycling
From: Joe Perches @ 2011-12-04 17:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1323018317.2762.143.camel@edumazet-laptop>
On Sun, 2011-12-04 at 18:05 +0100, Eric Dumazet wrote:
> If our TCP_PAGE(sk) is not shared (page_count() == 1), we can set page
> offset to 0.
[]
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
[]
> @@ -1009,7 +1009,12 @@ new_segment:
> int merge = 0;
> int i = skb_shinfo(skb)->nr_frags;
> struct page *page = TCP_PAGE(sk);
> - int off = TCP_OFF(sk);
> + int off;
> +
> + if (page && page_count(page) == 1)
> + TCP_OFF(sk) = 0;
> +
> + off = TCP_OFF(sk);
This might be clearer and take one less indirection as
if (page && page_count(page) == 1) {
TCP_OFF(sk) = 0;
off = 0;
} else {
off = 0;
}
or maybe
if (page && page_count(page) == 1)
off = TCP_OFF(sk) = 0;
else
off = 0;
And maybe the TCP_OFF and TCP_PAGE macros should be removed.
^ permalink raw reply
* [PATCH net-next] tcp: tcp_sendmsg() page recycling
From: Eric Dumazet @ 2011-12-04 17:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev
If our TCP_PAGE(sk) is not shared (page_count() == 1), we can set page
offset to 0.
This permits better filling of the pages on small to medium tcp writes.
"tbench 16" results on my dev server (2x4x2 machine) :
Before : 3072 MB/s
After : 3146 MB/s (2.4 % gain)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/tcp.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 45156be..a09fe25 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1009,7 +1009,12 @@ new_segment:
int merge = 0;
int i = skb_shinfo(skb)->nr_frags;
struct page *page = TCP_PAGE(sk);
- int off = TCP_OFF(sk);
+ int off;
+
+ if (page && page_count(page) == 1)
+ TCP_OFF(sk) = 0;
+
+ off = TCP_OFF(sk);
if (skb_can_coalesce(skb, i, page, off) &&
off != PAGE_SIZE) {
^ permalink raw reply related
* RE: [PATCH net-next V0 18/21] mlx4_core: adjust catas operation for SRIOV mode
From: Liran Liss @ 2011-12-04 15:45 UTC (permalink / raw)
To: Roland Dreier, Yevgeny Petrilin
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org
In-Reply-To: <CAL1RGDWp2fysTgVgSi30X+nf=66fArPRdXUXedbKxKjyHQqidQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> On Fri, Dec 2, 2011 at 2:19 AM, Yevgeny Petrilin
> <yevgenyp-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org> wrote:
> > When running in SRIOV mode, driver should not automatically
> start/stop
> > the mlx4_core upon sensing an HCA internal error -- doing this
> disables/enables
> > sriov, which will cause the hypervisor to hang if there are running
> VMs with
> > attached VFs.
>
> Not sure I understand this -- what happens if the driver doesn't reset
> the device
> after a catastrophic error? Surely all the VFs are pretty screwed at
> that point?
>
> Which hypervisor are we talking about here anyway?
>
> - R.
Indeed, if you don't reset the device after an internal error, the PF/VF might not work properly unless you reload the PF driver.
However, invoking the SW reset by the PF (upon detecting an internal error) currently affects the SRIOV capability on the PCI so we cannot do it before disabling SRIOV first.
Since the driver is not in charge of passing-through VFs to VMs, it cannot disable SRIOV either so we cannot reset the device while using SRIOV.
Note that the single-function behavior is not modified.
We intend to post a fix for this in a different patch-set.
--Liran
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next V0 19/21] mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
From: Or Gerlitz @ 2011-12-04 15:39 UTC (permalink / raw)
To: Jack Morgenstein
Cc: Roland Dreier, Yevgeny Petrilin, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
liranl-VPRAkNaXOzVS1MOuV/RT9w
In-Reply-To: <201112041629.41466.jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
On 12/4/2011 4:29 PM, Jack Morgenstein wrote:
> If the kernel is not configured to support IOV, pci_enable_sriov will
> fail.
Jack,
If CONFIG_PCI_IOV isn't set, pci_enable_sriov isn't there...
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next V0 19/21] mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
From: Jack Morgenstein @ 2011-12-04 14:29 UTC (permalink / raw)
To: Roland Dreier
Cc: Yevgeny Petrilin, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
liranl-VPRAkNaXOzVS1MOuV/RT9w
In-Reply-To: <CAL1RGDV8LzSOei=aQW7VXUP=G+9qdO+Y4eKZu8mBuHJuUp8UuQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Friday 02 December 2011 19:51, Roland Dreier wrote:
> > #else /* CONFIG_PCI_IOV */
> > +static int sr_iov;
> > +#define probe_vf 0
> > int mlx4_log_num_mgm_entry_size = 9;
> > #endif /* CONFIG_PCI_IOV */
>
> I don't think it's a good idea to put module parameters inside an
> #ifdef. Then depending on the
> kernel config someone compiles with, their modprobe.conf may or may not break.
>
I agree. I will change this so that the module parameters are always there.
If the kernel is not configured to support IOV, pci_enable_sriov will fail.
Currently, we abort the device startup. I can change this to simply continue
without sriov enabled:
======================================================
mlx4_core: fix sriov module parameters
Always have the sr_iov module parameters (even if the kernel
is not compiled with sriov support). Change device startup logic
so that if pci_enable_sriov() fails, the PF-driver continues to bring up
the device, but in non-sriov mode.
Signed-off-by: Jack Morgenstein <jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
---
Roland,
I will roll this change into the original patch set, so that V1 will contain
this code.
Index: net-next/drivers/net/ethernet/mellanox/mlx4/main.c
===================================================================
--- net-next.orig/drivers/net/ethernet/mellanox/mlx4/main.c 2011-12-04 10:38:52.000000000 +0200
+++ net-next/drivers/net/ethernet/mellanox/mlx4/main.c 2011-12-04 16:23:33.000000000 +0200
@@ -76,8 +76,6 @@ MODULE_PARM_DESC(msi_x, "attempt to use
#endif /* CONFIG_PCI_MSI */
-#ifdef CONFIG_PCI_IOV
-
static int sr_iov;
module_param(sr_iov, int, 0444);
MODULE_PARM_DESC(sr_iov, "enable #sr_iov functions if sr_iov > 0");
@@ -94,12 +92,6 @@ MODULE_PARM_DESC(log_num_mgm_entry_size,
" 10 gives 248.range: 9<="
" log_num_mgm_entry_size <= 12");
-#else /* CONFIG_PCI_IOV */
-static int sr_iov;
-#define probe_vf 0
-int mlx4_log_num_mgm_entry_size = 9;
-#endif /* CONFIG_PCI_IOV */
-
#define MLX4_VF (1 << 0)
#define HCA_GLOBAL_CAP_MASK 0
@@ -1732,13 +1724,19 @@ static int __mlx4_init_one(struct pci_de
if (sr_iov) {
mlx4_warn(dev, "Enabling sriov with:%d vfs\n", sr_iov);
- if (pci_enable_sriov(pdev, sr_iov)) {
- mlx4_err(dev, "Failed to enable sriov, aborting.\n");
- goto err_rel_own;
+ err = pci_enable_sriov(pdev, sr_iov);
+ if (err) {
+ mlx4_err(dev, "Failed to enable sriov,"
+ "continuing without sriov enabled"
+ " (err = %d).\n", err);
+ sr_iov = 0;
+ err = 0;
+ } else {
+ mlx4_warn(dev, "Running in master mode\n");
+ dev->flags |= MLX4_FLAG_SRIOV |
+ MLX4_FLAG_MASTER;
+ dev->sr_iov = sr_iov;
}
- mlx4_warn(dev, "Running in master mode\n");
- dev->flags |= MLX4_FLAG_SRIOV | MLX4_FLAG_MASTER;
- dev->sr_iov = sr_iov;
}
/*
- Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Understanding HFSC
From: Michal Soltys @ 2011-12-04 12:38 UTC (permalink / raw)
To: John A. Sullivan III; +Cc: netdev
In-Reply-To: <1322974639.3347.72.camel@denise.theartistscloset.com>
On 11-12-04 05:57, John A. Sullivan III wrote:
> Hello, all. I hope I am in the right place as this seems to be the
> place to ask questions formerly asked on lartc. For the last three
> days, I've been banging my head against the wall trying to understand
> HFSC and it's finally starting to crack (the wall, not my head
> although that's close, too!). It seems to be wonderful, powerful,
> mysterious, and poorly understood.
>
> I'm not sure I understand it either but it also seems much of what is
> written about it is written by people who don't fully grasp it, e.g.,
> mostly focusing on guaranteed bandwidth and hierarchical sharing but
> not spending much time explaining the important concept of decoupling
> latency requirements and bandwidth - the part most interesting to us.
> So I'm hoping you'll indulge my questions and my attempt to articulate
> my understanding to see if I get it or if I've completely missed the
> plot!
>
> One of the most confusing bits to me is, does the m1 rate apply to
> each flow handled by the class or only to the entire class once it
> becomes active?
Where a packet lands is (generally) determined by tc filters and/or
iptables' mark/classify targets. All the packets that end in some leaf
node, are governed by that node's realtime service curve, and at times
when that criterion is not used - at the ratio of virtual times (coming
from linkshare service curves) between that node and its siblings.
Regardless of curve used - smallest vt (linkshare criterion) or smallest
dt from all eligible (realtime criterion) wins, and the leaf with one
will fulfill the dequeue call.
If you need more fine grained control "below" such leaf node - you need
to either use deeper hierarchy with presumably "simpler" qdiscs attached
(but more complex marking setup), or shallower hierarchy with more
elaborate qdiscs attached. Think of work conserving qdiscs such as: sfq,
drr - paired with appropriate tc filters (tc-flow perhaps ?) as needed.
Btw - check out the very latest iproute2 tree - there're fresh
tc-hfsc(7) and tc-stab(8) manuals added. I tried to make them as
detailed as possible, but I might have overshot a bit - so opinion of
someone getting into hfsc territory is invaluable. You can read them (if
installing fresh iproute2 is out of question) with simple:
nroff -mandoc -rLL=<width>n <page> | less
http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=blob_plain;f=man/man7/tc-hfsc.7;hb=HEAD
http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=blob_plain;f=man/man8/tc-stab.8;hb=HEAD
> Second, what must go into the umax size? Let's assume we want umax to
> be a single maximum sized packet on a non-jumbo frame Ethernet
> network.
> Should umax be:
> 1500
> 1514 (add Ethernet)
> 1518 (add CRC)
> 1526 (add preamble)
> 1538 (add interframe gap)?
>
> To keep this email from growing any longer, I'll put the rest in a
> separate email? Thanks - John
>
Note: umax/dmax/rate and m1/d/m2 are just alternative ways to specify
the very same thing.
As for your question - in that particular case, assuming no vlan tags
either, that would be 1514, afaik. You can cover for the rest though
with tc-stab (and also for other layers, such as atm). Keep in mind,
that if you don't disable send offloading (usually enabled by default
these days), qdiscs might be dealing with e.g. massive tcp segments with
typical side effects.
I'll go through your other questions a bit later.
^ permalink raw reply
* RE: [PATCH net-next V0 03/21] mlx4_core: Add "native" argument to mlx4_cmd and its callers (where needed)
From: Yevgeny Petrilin @ 2011-12-04 10:43 UTC (permalink / raw)
To: Roland Dreier
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Liran Liss,
jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org
In-Reply-To: <CAL1RGDXh0-v075fdxvoA=sL0vOq1ncouNNH5v3y7QFHJmnnQEA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> > return mlx4_cmd(dev, limit_watermark, srq_num, 0, MLX4_CMD_ARM_SRQ,
> > - MLX4_CMD_TIME_CLASS_B);
> > + MLX4_CMD_TIME_CLASS_B, 0);
>
> Instead of a 0 or 1 for the native parameter, can we define something like
>
> enum {
> MLX4_CMD_NATIVE,
> MLX4_CMD_WRAPPED
> };
>
> so that all these calls become easier to read?
Agree,
We will change this for next round.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* [PATCHv2 net-next 4/4] caif: Stash away hijacked skb destructor and call it later
From: Sjur Brændeland @ 2011-12-04 10:10 UTC (permalink / raw)
To: netdev, David Miller; +Cc: Alexey Orishko, Eric Dumazet, Sjur Brændeland
In-Reply-To: <1322993450-8802-1-git-send-email-sjur.brandeland@stericsson.com>
This patch adds functionality for avoiding orphaning SKB too early.
The original skb is stashed away and the original destructor is called
from the hi-jacked flow-on callback. If CAIF interface goes down and a
hi-jacked SKB exists, the original skb->destructor is restored.
Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
---
This functionality is added after V1 of this patchset.
net/caif/caif_dev.c | 34 +++++++++++++++++++++++++++++++++-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/net/caif/caif_dev.c b/net/caif/caif_dev.c
index 1980404..a82d89f 100644
--- a/net/caif/caif_dev.c
+++ b/net/caif/caif_dev.c
@@ -37,6 +37,8 @@ struct caif_device_entry {
struct net_device *netdev;
int __percpu *pcpu_refcnt;
spinlock_t flow_lock;
+ struct sk_buff *xoff_skb;
+ void (*xoff_skb_dtor)(struct sk_buff *skb);
bool xoff;
};
@@ -134,6 +136,7 @@ static struct caif_device_entry *caif_get(struct net_device *dev)
void caif_flow_cb(struct sk_buff *skb)
{
struct caif_device_entry *caifd;
+ void (*dtor)(struct sk_buff *skb) = NULL;
bool send_xoff;
WARN_ON(skb->dev == NULL);
@@ -146,8 +149,17 @@ void caif_flow_cb(struct sk_buff *skb)
spin_lock_bh(&caifd->flow_lock);
send_xoff = caifd->xoff;
caifd->xoff = 0;
+ if (!WARN_ON(caifd->xoff_skb_dtor == NULL)) {
+ WARN_ON(caifd->xoff_skb != skb);
+ dtor = caifd->xoff_skb_dtor;
+ caifd->xoff_skb = NULL;
+ caifd->xoff_skb_dtor = NULL;
+ }
spin_unlock_bh(&caifd->flow_lock);
+ if (dtor)
+ dtor(skb);
+
if (send_xoff)
caifd->layer.up->
ctrlcmd(caifd->layer.up,
@@ -211,8 +223,10 @@ static int transmit(struct cflayer *layer, struct cfpkt *pkt)
netif_queue_stopped(caifd->netdev),
qlen, high);
caifd->xoff = 1;
+ caifd->xoff_skb = skb;
+ caifd->xoff_skb_dtor = skb->destructor;
+ skb->destructor = caif_flow_cb;
spin_unlock_bh(&caifd->flow_lock);
- skb_orphan(skb);
caifd->layer.up->ctrlcmd(caifd->layer.up,
_CAIF_CTRLCMD_PHYIF_FLOW_OFF_IND,
@@ -420,6 +434,24 @@ static int caif_device_notify(struct notifier_block *me, unsigned long what,
caifd->layer.up->ctrlcmd(caifd->layer.up,
_CAIF_CTRLCMD_PHYIF_DOWN_IND,
caifd->layer.id);
+
+ spin_lock_bh(&caifd->flow_lock);
+
+ /*
+ * Replace our xoff-destructor with original destructor.
+ * We trust that skb->destructor *always* is called before
+ * the skb reference is invalid. The hijacked SKB destructor
+ * takes the flow_lock so manipulating the skb->destructor here
+ * should be safe.
+ */
+ if (caifd->xoff_skb_dtor != NULL && caifd->xoff_skb != NULL)
+ caifd->xoff_skb->destructor = caifd->xoff_skb_dtor;
+
+ caifd->xoff = 0;
+ caifd->xoff_skb_dtor = NULL;
+ caifd->xoff_skb = NULL;
+
+ spin_unlock_bh(&caifd->flow_lock);
caifd_put(caifd);
break;
--
1.7.0.4
^ 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