* Re: [PATCH 2/2] act_mirred: optimization
From: Changli Gao @ 2009-11-16 13:22 UTC (permalink / raw)
To: David Miller; +Cc: hadi, shemminger, netdev
In-Reply-To: <20091116.051722.255835290.davem@davemloft.net>
On Mon, Nov 16, 2009 at 9:17 PM, David Miller <davem@davemloft.net> wrote:
> From: Changli Gao <xiaosuo@gmail.com>
> Date: Mon, 16 Nov 2009 21:05:28 +0800
>
>> I am sorry about that. But I did test it before submitting these two,
>> and I am just wondering if they are applied without any error. Would
>> you post the file after being patched? I think it will be helpful to
>> finger out the real problem.
>
> I don't have time for that sorry.
Thanks all the same!
>
> I think the problem might be that you are developing against
> either net-2.6 or Linus's tree, whereas you should be working
> against net-next-2.6
>
I am working against linux-next. I'll check if there is any
difference. BTW: were these patches applied in order, 1 - 2?
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [RFC-PATCH] libiscsi dhcp handler
From: David Miller @ 2009-11-16 13:18 UTC (permalink / raw)
To: rakesh; +Cc: michaelc, open-iscsi, netdev, linux-kernel, James.Bottomley, kxie
In-Reply-To: <4B014F95.8000906@chelsio.com>
From: Rakesh Ranjan <rakesh@chelsio.com>
Date: Mon, 16 Nov 2009 18:41:49 +0530
> Herein attached patches to support dhcp based provisioning for iSCSI
> offload capable cards. I have made dhcp code as generic as possible,
> please go through the code. Based on the feedback I will submit final
> version of these patches.
You can't really add objects to the build before the patch that
adds the source for that object.
^ permalink raw reply
* Re: [PATCH 2/2] act_mirred: optimization
From: David Miller @ 2009-11-16 13:17 UTC (permalink / raw)
To: xiaosuo; +Cc: hadi, shemminger, netdev
In-Reply-To: <412e6f7f0911160505x10da9a92j694669db9d030da1@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Mon, 16 Nov 2009 21:05:28 +0800
> I am sorry about that. But I did test it before submitting these two,
> and I am just wondering if they are applied without any error. Would
> you post the file after being patched? I think it will be helpful to
> finger out the real problem.
I don't have time for that sorry.
I think the problem might be that you are developing against
either net-2.6 or Linus's tree, whereas you should be working
against net-next-2.6
^ permalink raw reply
* [RFC-PATCH] libiscsi dhcp handler
From: Rakesh Ranjan @ 2009-11-16 13:11 UTC (permalink / raw)
To: Mike Christie
Cc: open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA, LKML, David Miller,
James Bottomley, Karen Xie, Rakesh Ranjan
[-- Attachment #1: Type: text/plain, Size: 748 bytes --]
Hi mike,
Herein attached patches to support dhcp based provisioning for iSCSI
offload capable cards. I have made dhcp code as generic as possible,
please go through the code. Based on the feedback I will submit final
version of these patches.
Regards
Rakesh Ranjan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Required-changes-for-libiscsi-to-support-dhcp-based.patch --]
[-- Type: text/x-patch, Size: 4284 bytes --]
>From 472d53f2ca0122b7fbfeabbcbde2c9a15499042b Mon Sep 17 00:00:00 2001
From: Rakesh Ranjan <rakesh-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
Date: Mon, 16 Nov 2009 18:11:56 +0530
Subject: [PATCH 1/2] Required changes for libiscsi to support dhcp based provisioning for offload capable cards.
These changes adds ISCSI_UEVENT_REQ_IPCONF message to invoke dhcp handler.
Signed-off-by: Rakesh Ranjan <rakesh-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
---
Makefile | 3 ++-
include/scsi/iscsi_if.h | 4 ++++
include/scsi/libiscsi.h | 20 ++++++++++++++++++++
include/scsi/scsi_transport_iscsi.h | 1 +
scsi_transport_iscsi.c | 25 +++++++++++++++++++++++++
5 files changed, 52 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 26d33e5..3e5d461 100644
--- a/Makefile
+++ b/Makefile
@@ -2,10 +2,11 @@
# libiscsi modules
#
ifneq ($(KERNELRELEASE),)
- obj-m += libiscsi.o
obj-m += libiscsi_tcp.o
obj-m += scsi_transport_iscsi.o
obj-m += iscsi_tcp.o
+ obj-m += libiscsi.o
+ obj-m += libiscsi_ipconfig.o
EXTRA_CFLAGS += -I$(src)/include
else
diff --git a/include/scsi/iscsi_if.h b/include/scsi/iscsi_if.h
index d67dda2..135f229 100644
--- a/include/scsi/iscsi_if.h
+++ b/include/scsi/iscsi_if.h
@@ -59,6 +59,7 @@ enum iscsi_uevent_e {
ISCSI_UEVENT_TRANSPORT_EP_CONNECT_THROUGH_HOST = UEVENT_BASE + 19,
ISCSI_UEVENT_PATH_UPDATE = UEVENT_BASE + 20,
+ ISCSI_UEVENT_REQ_IPCONF = UEVENT_BASE + 21,
/* up events */
ISCSI_KEVENT_RECV_PDU = KEVENT_BASE + 1,
@@ -172,6 +173,9 @@ struct iscsi_uevent {
struct msg_set_path {
uint32_t host_no;
} set_path;
+ struct mag_req_ipconf {
+ uint32_t host_no;
+ } req_ipconf;
} u;
union {
/* messages k -> u */
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index a72edd4..a9af95e 100644
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -330,6 +330,18 @@ struct iscsi_host {
char workq_name[20];
};
+/* libiscsi ipconfig */
+struct dhcp_info {
+ __be32 ltime;
+ __be32 serverid;
+ __be32 ipaddr;
+ __be32 netmask;
+ __be32 dnsaddr;
+ __be32 gipaddr;
+ __u8 *mac_addr;
+};
+
+
/*
* scsi host template
*/
@@ -427,6 +439,14 @@ extern void iscsi_pool_free(struct iscsi_pool *);
extern int iscsi_pool_init(struct iscsi_pool *, int, void ***, int);
/*
+ * libiscsi ipconfig helpers
+ */
+extern int libiscsi_do_ipconf(struct net_device *ndev,
+ struct dhcp_info *dinfo);
+extern int libiscsi_ipconfig_recv(struct net_device *ndev,
+ struct sk_buff *skb);
+
+/*
* inline functions to deal with padding.
*/
static inline unsigned int
diff --git a/include/scsi/scsi_transport_iscsi.h b/include/scsi/scsi_transport_iscsi.h
index 349c7f3..3e5fd96 100644
--- a/include/scsi/scsi_transport_iscsi.h
+++ b/include/scsi/scsi_transport_iscsi.h
@@ -134,6 +134,7 @@ struct iscsi_transport {
int (*tgt_dscvr) (struct Scsi_Host *shost, enum iscsi_tgt_dscvr type,
uint32_t enable, struct sockaddr *dst_addr);
int (*set_path) (struct Scsi_Host *shost, struct iscsi_path *params);
+ int (*req_ipconf) (struct Scsi_Host *shost);
};
/*
diff --git a/scsi_transport_iscsi.c b/scsi_transport_iscsi.c
index ad897df..4897a3f 100644
--- a/scsi_transport_iscsi.c
+++ b/scsi_transport_iscsi.c
@@ -1508,6 +1508,28 @@ iscsi_set_path(struct iscsi_transport *transport, struct iscsi_uevent *ev)
}
static int
+iscsi_req_ipconf(struct iscsi_transport *transport, struct iscsi_uevent *ev)
+{
+ struct Scsi_Host *shost;
+ int err;
+
+ if (!transport->req_ipconf)
+ return -ENOSYS;
+
+ shost = scsi_host_lookup(ev->u.req_ipconf.host_no);
+ if (!shost) {
+ printk(KERN_ERR "ipconf req could not find host no %u\n",
+ ev->u.req_ipconf.host_no);
+ return -ENODEV;
+ }
+
+ err = transport->req_ipconf(shost);
+
+ scsi_host_put(shost);
+ return err;
+}
+
+static int
iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
{
int err = 0;
@@ -1627,6 +1649,9 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
case ISCSI_UEVENT_PATH_UPDATE:
err = iscsi_set_path(transport, ev);
break;
+ case ISCSI_UEVENT_REQ_IPCONF:
+ err = iscsi_req_ipconf(transport, ev);
+ break;
default:
err = -ENOSYS;
break;
--
1.6.0.6
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-dhcp-handler-for-libiscsi-to-support-dhcp-provisioni.patch --]
[-- Type: text/x-patch, Size: 11364 bytes --]
>From 8df0fd4d0a972bd76bb71d7fdac274b273cec50d Mon Sep 17 00:00:00 2001
From: Rakesh Ranjan <rakesh-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
Date: Mon, 16 Nov 2009 18:32:57 +0530
Subject: [PATCH 2/2] dhcp handler for libiscsi to support dhcp provisioning for offload capable cards.
This module contains a compact dhcp handler to support dhcp based provisioning for
offload capable cards.
Signed-off-by: Rakesh Ranjan <rakesh-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
---
libiscsi_ipconfig.c | 466 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 466 insertions(+), 0 deletions(-)
create mode 100644 libiscsi_ipconfig.c
diff --git a/libiscsi_ipconfig.c b/libiscsi_ipconfig.c
new file mode 100644
index 0000000..4057aae
--- /dev/null
+++ b/libiscsi_ipconfig.c
@@ -0,0 +1,466 @@
+/* libiscsi_ipconfig.c: libiscsi dhcp client.
+ *
+ * Copyright (c) 2009 Chelsio Communications, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ *
+ * Written by: Rakesh Ranjan (rakesh-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org)
+ */
+
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/in.h>
+#include <linux/delay.h>
+#include <linux/if_arp.h>
+#include <net/ip.h>
+#include <scsi/iscsi_if.h>
+#include <scsi/libiscsi.h>
+
+#define DHCP_REQUEST 1
+#define DHCP_REPLY 2
+#define DHCP_HTYPE_ETHERNET 1
+#define DHCP_HLEN_ETHERNET 6
+#define DHCP_MSG_LEN 236
+
+#define DHCPC_SERVER_PORT 67
+#define DHCPC_CLIENT_PORT 68
+
+/* DHCP message types */
+#define DHCPDISCOVER 1
+#define DHCPOFFER 2
+#define DHCPREQUEST 3
+#define DHCPDECLINE 4
+#define DHCPACK 5
+#define DHCPNAK 6
+#define DHCPRELEASE 7
+#define DHCPINFORM 8
+
+/* DHCP options */
+#define DHCP_OPTION_SUBNET_MASK 1
+#define DHCP_OPTION_ROUTER 3
+#define DHCP_OPTION_DNS_SERVER 6
+#define DHCP_OPTION_MTU 26
+#define DHCP_OPTION_REQ_IPADDR 50
+#define DHCP_OPTION_LEASE_TIME 51
+#define DHCP_OPTION_MSG_TYPE 53
+#define DHCP_OPTION_SERVER_ID 54
+#define DHCP_OPTION_REQ_LIST 55
+#define DHCP_OPTION_VCID 60
+#define DHCP_OPTION_END 255
+
+enum {
+ STATE_INIT = 0,
+ STATE_SENDING,
+ STATE_OFFER_REC,
+ STATE_CONFIG_REC,
+};
+
+struct dhcp_pkt {
+ struct iphdr iph;
+ struct udphdr udph;
+ u8 op;
+ u8 htype;
+ u8 hlen;
+ u8 hops;
+ __be32 xid;
+ __be16 secs;
+ __be16 flags;
+ __be32 cipaddr;
+ __be32 yipaddr;
+ __be32 sipaddr;
+ __be32 ripaddr;
+ u8 chwaddr[16];
+ u8 sname[64];
+ u8 bfile[128];
+ u8 options[312];
+};
+
+
+static struct dhcp_client_state {
+ struct sk_buff *skb;
+ struct dhcp_pkt *pkt;
+ struct net_device *ndev;
+ struct list_head list;
+ struct dhcp_info dinfo;
+
+ volatile __u8 state;
+ __be32 xid;
+
+} client_state;
+
+static DEFINE_SPINLOCK(rcv_lock);
+
+static const char *RFC2132_VENDOR_CLASS_ID = "libiscsi client";
+
+static const u8 magic_cookie[4] = { 99, 130, 83, 99 };
+
+static inline u8 *add_msg_type(u8 *optptr, u8 type)
+{
+ *optptr++ = DHCP_OPTION_MSG_TYPE;
+ *optptr++ = 1;
+ *optptr++ = type;
+ return optptr;
+}
+
+static inline u8 *add_req_options(u8 *optptr)
+{
+ *optptr++ = DHCP_OPTION_REQ_LIST;
+ *optptr++ = 4;
+ *optptr++ = DHCP_OPTION_SUBNET_MASK;
+ *optptr++ = DHCP_OPTION_ROUTER;
+ *optptr++ = DHCP_OPTION_DNS_SERVER;
+ *optptr++ = DHCP_OPTION_MTU;
+ return optptr;
+}
+
+static inline u8 *add_vendor_cid(u8 *optptr)
+{
+ u8 len = strlen(RFC2132_VENDOR_CLASS_ID);
+ *optptr++ = DHCP_OPTION_VCID;
+ *optptr++ = len;
+ memcpy(optptr, RFC2132_VENDOR_CLASS_ID, len);
+ optptr += len;
+ return optptr;
+}
+
+static inline u8 *add_server_id(__be32 *sid, u8 *optptr)
+{
+ *optptr++ = DHCP_OPTION_SERVER_ID;
+ *optptr++ = 4;
+ memcpy(optptr, sid, 4);
+ return optptr + 4;
+}
+
+static inline u8 *add_req_ipaddr(__be32 *ip, u8 *optptr)
+{
+ *optptr++ = DHCP_OPTION_REQ_IPADDR;
+ *optptr++ = 4;
+ memcpy(optptr, ip, 4);
+ return optptr + 4;
+}
+
+static inline u8 *add_end(u8 *optptr)
+{
+ *optptr++ = DHCP_OPTION_END;
+ return optptr;
+}
+
+static void
+libiscsi_process_dhcp_opts(struct dhcp_client_state *client, u8 *optptr,
+ int len)
+{
+ u8 *end = optptr + len;
+ u8 type = 0;
+
+ while (optptr < end) {
+ switch (*optptr) {
+ case DHCP_OPTION_SUBNET_MASK:
+ memcpy(&client->dinfo.netmask, optptr + 2, 4);
+ break;
+ case DHCP_OPTION_ROUTER:
+ memcpy(&client->dinfo.gipaddr, optptr + 2, 4);
+ break;
+ case DHCP_OPTION_DNS_SERVER:
+ memcpy(&client->dinfo.dnsaddr, optptr + 2, 4);
+ break;
+ case DHCP_OPTION_MSG_TYPE:
+ type = *(optptr + 2);
+ if (type == DHCPOFFER)
+ client->state = STATE_OFFER_REC;
+ else if (type == DHCPACK)
+ client->state = STATE_CONFIG_REC;
+ break;
+ case DHCP_OPTION_SERVER_ID:
+ memcpy(&client->dinfo.serverid, optptr + 2, 4);
+ break;
+ case DHCP_OPTION_LEASE_TIME:
+ memcpy(&client->dinfo.ltime, optptr + 2, 4);
+ break;
+ case DHCP_OPTION_END:
+ break;
+ }
+
+ optptr += optptr[1] + 2;
+ }
+}
+
+static void
+libiscsi_process_dhcp_pack(struct dhcp_client_state *client,
+ struct dhcp_pkt *pkt)
+{
+ u8 *start, *end;
+ int opt_len;
+
+ start = &pkt->options[4];
+ end = (u8 *) pkt + ntohs(pkt->iph.tot_len);
+ opt_len = end - start;
+
+ if (pkt->op == DHCP_REPLY &&
+ !memcmp(&pkt->xid, &client->xid, sizeof(client->xid)) &&
+ !memcmp(pkt->chwaddr, client->dinfo.mac_addr, pkt->hlen)) {
+ memcpy(&client->dinfo.ipaddr, &pkt->yipaddr, 4);
+ libiscsi_process_dhcp_opts(client, start, opt_len);
+ }
+}
+
+static int
+libiscsi_ipconfig_send(struct dhcp_client_state *client)
+{
+ int rc = 0;
+ struct sk_buff *lskb = client->skb;
+
+ lskb->dev = client->ndev;
+ lskb->protocol = htons(ETH_P_IP);
+
+ dev_hard_header(lskb, client->ndev, ntohs(lskb->protocol),
+ client->ndev->broadcast,
+ client->dinfo.mac_addr, lskb->len);
+ rc = dev_queue_xmit(lskb);
+
+ return rc;
+}
+
+int
+libiscsi_ipconfig_recv(struct net_device *ndev, struct sk_buff *skb)
+{
+ struct iphdr *iph;
+ struct udphdr *udph;
+ struct ethhdr *eh;
+ struct dhcp_pkt *pkt;
+ struct sk_buff *pskb;
+ int len, opts_len;
+ struct dhcp_client_state *client;
+ int rc = 0;
+
+
+ client = &client_state;
+
+ if (unlikely(client->state == STATE_INIT))
+ goto out;
+
+ if (skb->pkt_type != PACKET_OTHERHOST)
+ goto out;
+
+ pskb = skb_copy(skb, GFP_ATOMIC);
+ if (!pskb) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ eh = eth_hdr(pskb);
+ if (!is_valid_ether_addr(eh->h_dest))
+ goto drop;
+
+ if (compare_ether_addr(eh->h_dest, client->dinfo.mac_addr))
+ goto drop;
+
+ if (!pskb_may_pull(pskb, sizeof(struct iphdr) + sizeof(struct udphdr)))
+ goto drop;
+
+
+ skb_reset_network_header(pskb);
+ pkt = (struct dhcp_pkt *) skb_network_header(pskb);
+ iph = &pkt->iph;
+
+ if (iph->ihl != 5 || iph->version != 4 || iph->protocol != IPPROTO_UDP)
+ goto drop;
+
+ if (iph->frag_off & htons(IP_OFFSET | IP_MF))
+ goto drop;
+
+ if (skb->len < ntohs(iph->tot_len))
+ goto drop;
+
+ if (ip_fast_csum((u8 *)iph, iph->ihl))
+ goto drop;
+
+ udph = &pkt->udph;
+ if (udph->source != htons(67) || udph->dest != htons(68))
+ goto drop;
+
+ if (ntohs(iph->tot_len) < ntohs(udph->len) + sizeof(struct iphdr))
+ goto drop;
+
+ len = ntohs(udph->len) - sizeof(struct udphdr);
+ opts_len = len - (sizeof(*pkt) -
+ sizeof(struct iphdr) -
+ sizeof(struct udphdr) -
+ sizeof(pkt->options));
+ if (opts_len < 0)
+ goto drop;
+
+ if (memcmp(pkt->options, magic_cookie, 4))
+ goto drop;
+
+ spin_lock(&rcv_lock);
+
+ libiscsi_process_dhcp_pack(client, pkt);
+
+ spin_unlock(&rcv_lock);
+
+drop:
+ kfree(pskb);
+out:
+ return rc;
+}
+EXPORT_SYMBOL(libiscsi_ipconfig_recv);
+
+static int
+libiscsi_create_dhcp_msg(struct dhcp_client_state *client)
+{
+ struct iphdr *iph;
+ struct udphdr *udph;
+ struct sk_buff *skb;
+ struct dhcp_pkt *pkt;
+ int rc = 0;
+
+ skb = alloc_skb(sizeof(*pkt) +
+ LL_ALLOCATED_SPACE(client->ndev) + 15,
+ GFP_KERNEL);
+ if (!skb) {
+ rc = -ENOMEM;
+ return rc;
+ }
+
+ client->skb = skb;
+ skb_reserve(skb, LL_RESERVED_SPACE(client->ndev));
+
+ pkt = (struct dhcp_pkt *) skb_put(skb, sizeof(*pkt));
+ BUG_ON(!pkt);
+ client->pkt = pkt;
+ memset(pkt, 0, sizeof(*pkt));
+
+ skb_reset_network_header(skb);
+
+ /* construct IP header */
+ iph = &pkt->iph;
+ iph->version = 4;
+ iph->ihl = 5;
+ iph->tot_len = htons(sizeof(struct dhcp_pkt));
+ iph->frag_off = htons(IP_DF);
+ iph->ttl = 64;
+ iph->protocol = IPPROTO_UDP;
+ iph->daddr = htonl(INADDR_BROADCAST);
+ iph->check = ip_fast_csum((u8 *) iph, iph->ihl);
+
+ /* Construct UDP header */
+ udph = &pkt->udph;
+ udph->source = htons(DHCPC_CLIENT_PORT);
+ udph->dest = htons(DHCPC_SERVER_PORT);
+ udph->len = htons(sizeof(struct dhcp_pkt) - sizeof(struct iphdr));
+
+ pkt->op = DHCP_REQUEST;
+ pkt->htype = DHCP_HTYPE_ETHERNET;
+ pkt->hlen = ETH_ALEN;
+
+ memcpy(pkt->chwaddr, client->dinfo.mac_addr, ETH_ALEN);
+ pkt->secs = htons(jiffies / HZ);
+ pkt->xid = client->xid;
+
+ memcpy(pkt->options, magic_cookie, sizeof(magic_cookie));
+
+ return rc;
+}
+
+static int libiscsi_send_dhcp_request(struct dhcp_client_state *client)
+{
+ int rc = 0;
+ u8 *end;
+
+ rc = libiscsi_create_dhcp_msg(client);
+ if (rc)
+ return rc;
+
+ end = add_msg_type(&client->pkt->options[4], DHCPREQUEST);
+ end = add_server_id(&client->dinfo.serverid, end);
+ end = add_req_ipaddr(&client->dinfo.ipaddr, end);
+ end = add_vendor_cid(end);
+ end = add_end(end);
+
+ rc = libiscsi_ipconfig_send(client);
+
+ return rc;
+}
+
+static int libiscsi_send_dhcp_discover(struct dhcp_client_state *client)
+{
+ int rc = 0;
+ u8 *end;
+
+ rc = libiscsi_create_dhcp_msg(client);
+ if (rc)
+ return rc;
+
+ end = add_msg_type(&client->pkt->options[4], DHCPDISCOVER);
+ end = add_req_options(end);
+ end = add_vendor_cid(end);
+ end = add_end(end);
+
+ client->state = STATE_SENDING;
+ rc = libiscsi_ipconfig_send(client);
+
+ return rc;
+}
+
+static void
+libiscsi_wait_for_pack(struct dhcp_client_state *client, u8 state)
+{
+ unsigned long tout, ntout;
+
+ get_random_bytes(&tout, sizeof(tout));
+ tout = (tout % (unsigned)HZ) + (HZ * 2);
+
+ ntout = jiffies + tout;
+ while (time_before(jiffies, ntout) && (client->state != state))
+ schedule_timeout_uninterruptible(1);
+}
+
+int libiscsi_do_ipconf(struct net_device *ndev, struct dhcp_info *dinfo)
+{
+ int rc = 0;
+ int retry;
+ struct dhcp_client_state *client;
+ retry = 2;
+
+ client = &client_state;
+ client->dinfo.mac_addr = dinfo->mac_addr;
+ client->ndev = ndev;
+ client->state = STATE_INIT;
+
+ /* show time */
+ for (;;) {
+ get_random_bytes(&client->xid, sizeof(__be32));
+ libiscsi_send_dhcp_discover(client);
+ libiscsi_wait_for_pack(client, STATE_OFFER_REC);
+
+ if (client->state == STATE_OFFER_REC) {
+ libiscsi_send_dhcp_request(client);
+ libiscsi_wait_for_pack(client, STATE_CONFIG_REC);
+ if (client->state == STATE_CONFIG_REC) {
+ dinfo->ipaddr = client->dinfo.ipaddr;
+ dinfo->netmask = client->dinfo.netmask;
+ dinfo->ltime = client->dinfo.ltime;
+ client->state = STATE_INIT;
+ break;
+ }
+ }
+
+ if (!--retry) {
+ rc = -ENETUNREACH;
+ break;
+ }
+ }
+
+ return rc;
+}
+EXPORT_SYMBOL(libiscsi_do_ipconf);
+
+MODULE_AUTHOR("Rakesh Ranjan");
+MODULE_DESCRIPTION("iSCSI ipconfig functions");
+MODULE_LICENSE("GPL");
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH] net/can: add driver for mscan family & mpc52xx_mscan
From: Wolfgang Grandegger @ 2009-11-16 13:08 UTC (permalink / raw)
To: Wolfram Sang
Cc: netdev, Grant Likely, socketcan-core, linuxppc-dev, David Miller
In-Reply-To: <20091116102414.GB30609@pengutronix.de>
Hi Wolfram,
Wolfram Sang wrote:
> Hi Wolfgang,
>
> On Mon, Nov 16, 2009 at 09:44:05AM +0100, Wolfgang Grandegger wrote:
>> Hi Wolfram,
>>
>> thanks for pushing this driver to mainline. I think you should also add
>> a CC to the Devicetree-discuss ML.
>
> thank you very much for your review! I agree with nearly all of your points and will
> send an update today. The only thing I have doubts about is removing those lines:
Thanks, quite a bit of work.
>> +MODULE_AUTHOR("Andrey Volkov <avolkov@varma-el.com>");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("CAN port driver for a MSCAN based chips");
>
> I looked around in the kernel sources and found that they are often present in
> generic modules, even if they can't be used without a wrapper (examples are all
> files in drivers/i2c/algos or drivers/net/wireless/iwlwifi/iwl-core.c). As I'm
> also a bit anxious to fiddle with other people's authorship, I'd prefer to keep
> them.
They do not harm, fine for me.
> Finally, I'll also try to test suspend/resume, but I have to find out if it is
> supported on that board in general.
Maybe somebody else already uses suspend/resume on a MPC5200 board with
Socket-CAN and could provide some feedback.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 2/2] act_mirred: optimization
From: Changli Gao @ 2009-11-16 13:05 UTC (permalink / raw)
To: David Miller; +Cc: hadi, shemminger, netdev
In-Reply-To: <20091116.025859.78494103.davem@davemloft.net>
On Mon, Nov 16, 2009 at 6:58 PM, David Miller <davem@davemloft.net> wrote:
> From: David Miller <davem@davemloft.net>
> Date: Mon, 16 Nov 2009 02:48:39 -0800 (PST)
>
>> From: Changli Gao <xiaosuo@gmail.com>
>> Date: Mon, 16 Nov 2009 17:53:29 +0800
>>
>>> act_mirred: optimization.
>>>
>>> move checking if eaction is valid in tcf_mirred_init()
>>>
>>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>>> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
>>
>> Also applied, thank you.
>
> Nevermind, you're NOT TESTING the patches you are posting:
>
> net/sched/act_mirred.c: In function ‘tcf_mirred’:
> net/sched/act_mirred.c:168: error: label ‘out’ used but not defined
> net/sched/act_mirred.c:158: warning: unused variable ‘err’
> net/sched/act_mirred.c:158: warning: unused variable ‘retval’
> make[2]: *** [net/sched/act_mirred.o] Error 1
> make[1]: *** [net/sched] Error 2
> make[1]: *** Waiting for unfinished jobs....
>
> I'm thus reverting both changes.
>
> Don't submit changes which are untested, it wastes my time.
>
I am sorry about that. But I did test it before submitting these two,
and I am just wondering if they are applied without any error. Would
you post the file after being patched? I think it will be helpful to
finger out the real problem.
BTW: since my email client thunderbird was broken, I used google
webmail(with ViewSourceWith addon) to submit these two patches.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [net-next] bnx2x: Handle Rx and Tx together in NAPI
From: David Miller @ 2009-11-16 12:24 UTC (permalink / raw)
To: B05799; +Cc: vladz, netdev, eilong
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B950C11@zin33exm22.fsl.freescale.net>
From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
Date: Mon, 16 Nov 2009 17:26:33 +0530
> In the current implemnetation, the ->poll() function does the cleanup of
> the tx and rx rings of the same device.
> In case of forwarding scenarios (for eg, eth0 --> eth1) we should clean
> the tx ring of eth1 so that the buffers can be reclaimed and they be
> reused for eth0 RX and same is the case for opposite flow. With the
> current implementation there will be a problem for the bidirectional
> flow as a ->poll() function will try to cleanup the rx and tx ring of
> the same device.
>
> Hence I feel, if we separate out the tx and rx clean ring processes, it
> would be more advantageous as the reclaim process can be more effective.
Eric Dumazet is working on patches to make sure the TX frees
get scheduled on the same CPU as they were transmitted on.
Therefore, you shouldn't try to approximate this in your driver.
^ permalink raw reply
* RE: [net-next] bnx2x: Handle Rx and Tx together in NAPI
From: Kumar Gopalpet-B05799 @ 2009-11-16 11:56 UTC (permalink / raw)
To: David Miller; +Cc: vladz, netdev, eilong
In-Reply-To: <20091116.030504.268003197.davem@davemloft.net>
>> I was talking about an independent napi routine for cleaning
>tx ring,
>> I do not want to mix the rx and tx clean ring processes.
>
>But you absolutely should do this, it will give optimal performance.
>
In the current implemnetation, the ->poll() function does the cleanup of
the tx and rx rings of the same device.
In case of forwarding scenarios (for eg, eth0 --> eth1) we should clean
the tx ring of eth1 so that the buffers can be reclaimed and they be
reused for eth0 RX and same is the case for opposite flow. With the
current implementation there will be a problem for the bidirectional
flow as a ->poll() function will try to cleanup the rx and tx ring of
the same device.
Hence I feel, if we separate out the tx and rx clean ring processes, it
would be more advantageous as the reclaim process can be more effective.
--
Thanks
Sandeep
^ permalink raw reply
* Re: [PATCH net] net: Fix the rollback test in dev_change_name()
From: David Miller @ 2009-11-16 11:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: jarkao2, netdev
In-Reply-To: <4B0132A6.7090305@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 16 Nov 2009 12:08:22 +0100
> David Miller a écrit :
>> From: Jarek Poplawski <jarkao2@gmail.com>
>> Date: Mon, 16 Nov 2009 09:30:24 +0000
>>
>>> From: Eric Dumazet <eric.dumazet@gmail.com>
>>>
>>> net: Fix the rollback test in dev_change_name()
>>>
>>> In dev_change_name() an err variable is used for storing the original
>>> call_netdevice_notifiers() errno (negative) and testing for a rollback
>>> error later, but the test for non-zero is wrong, because the err might
>>> have positive value as well - from dev_alloc_name(). It means the
>>> rollback for a netdevice with a number > 0 will never happen. (The err
>>> test is reordered btw. to make it more readable.)
>>>
>>> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
>>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
...
>> Eric please give your signoff and I'll put this where it needs
>> to go.
...
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-2.6 and queued for -stable, thanks everyone!
^ permalink raw reply
* Re: [net-next] bnx2x: Handle Rx and Tx together in NAPI
From: David Miller @ 2009-11-16 11:24 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADCB2D07B367@SJEXCHCCR02.corp.ad.broadcom.com>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Mon, 16 Nov 2009 03:11:27 -0800
> To say the truth, limiting the amount of Tx work done in one NAPI
> round is about to harm single NAPI performance, however I thought it
> would be a nice thing to do in global (all network devices/queues in
> the system) perspective. In Tx only case: when all NAPIs do only Tx
> DPC work (UDP Tx only case) I need to ensure fairness somehow, so I
> chose NAPI's budget. Could u advice on this?
The extra loop you'll trigger in the code above ->poll() that loops
over NAPI context is more expensive than the TX freeing work.
The size of your TX ring will be enough all by itself to ensure
enough fairness.
If you try to use the NAPI quota, you're just adding overhead.
> There is another decision to make: what to do when Rx hasn't
> consumed the whole budget and there is still Tx work to do. I think
> that in this case we need to return "budget", so that we pushed to
> the end on the local NAPI's list, "consuming" some global Rx budget
> of the local NAPI. Another option is to return the number of Rx
> packets handled and make this NAPI be called at once. My decision is
> based on the fact that there were scenarios when net_tx_action and
> net_rx_action were running on different CPUs in UDP Tx test and were
> feeding each other. In this case if I implemented the later option I
> would prevent other local NAPIs to run.
I think you should always process all of the pending TX work first,
then do RX work and base your budget and rescheduling decisions
purely on RX work.
If you want to see it codified look at the tg3 driver or any other
driver that has been NAPI for a long ti me.
^ permalink raw reply
* Re: [PATCH 1/2] rps: core implementation
From: David Miller @ 2009-11-16 11:19 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <65634d660911102253o2b4f7a19kfed5849e5c88bfe1@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Tue, 10 Nov 2009 22:53:17 -0800
> + /* Schedule NAPI for backlog device */
> + if (napi_schedule_prep(&queue->backlog)) {
> + if (cpu != smp_processor_id()) {
> + cpu_set(cpu,
> + get_cpu_var(rps_remote_softirq_cpus));
> + __raise_softirq_irqoff(NET_RPS_SOFTIRQ);
> + } else
> + __napi_schedule(&queue->backlog);
> + }
> + goto enqueue;
{,__}send_remote_softirq() doesn't work? :-)
^ permalink raw reply
* Re: [PATCH 1/2] rps: core implementation
From: David Miller @ 2009-11-16 11:15 UTC (permalink / raw)
To: eric.dumazet; +Cc: therbert, netdev
In-Reply-To: <4AFA73DA.30308@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 11 Nov 2009 09:20:42 +0100
> I think I'll try to extend your patches with TX completion recycling too.
>
> Ie record in skb the cpu number of original sender, and queue skb to
> remote queue for destruction (sock_wfree() call and expensive
> scheduler calls...)
>
> (This probably needs driver cooperation, instead of calling consume_skb(),
> use a different function)
You can add a new argument to consume_skb() which indicates to remote
schedule a local free.
I would also suggest to record the TX cpu at dev_hard_start_xmit()
time, rather than somewhere higher up such as the socket layer.
Otherwise you'll mess up routing/netfilter cases, and also mishandle
task migration.
But a very excellent idea.
^ permalink raw reply
* RE: [net-next] bnx2x: Handle Rx and Tx together in NAPI
From: Vladislav Zolotarov @ 2009-11-16 11:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Eilon Greenstein
In-Reply-To: <20091116.022012.81633492.davem@davemloft.net>
Ok. I'll fix it shortly and send u a new patch.
To say the truth, limiting the amount of Tx work done in one NAPI round is
about to harm single NAPI performance, however I thought it would be a nice thing to
do in global (all network devices/queues in the system) perspective. In Tx only
case: when all NAPIs do only Tx DPC work (UDP Tx only case) I need to ensure fairness
somehow, so I chose NAPI's budget. Could u advice on this?
There is another decision to make: what to do when Rx hasn't consumed the whole budget
and there is still Tx work to do. I think that in this case we need to return "budget", so that
we pushed to the end on the local NAPI's list, "consuming" some global Rx budget of the
local NAPI. Another option is to return the number of Rx
packets handled and make this NAPI be called at once. My decision is based on the fact
that there were scenarios when net_tx_action and net_rx_action were running on different
CPUs in UDP Tx test and were feeding each other. In this case if I implemented the later option
I would prevent other local NAPIs to run.
What is your opinion on this?
Thanks,
vlad
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, November 16, 2009 12:20 PM
> To: Vladislav Zolotarov
> Cc: netdev@vger.kernel.org; Eilon Greenstein
> Subject: Re: [net-next] bnx2x: Handle Rx and Tx together in NAPI
>
> From: "Vladislav Zolotarov" <vladz@broadcom.com>
> Date: Mon, 16 Nov 2009 12:01:09 +0200
>
> > - Limit Tx work done in one iteration by the same number
> of packets as
> > Rx in order to ensure both fair work load balancing
> relatively to other
> > devices scheduled for NAPI on the local CPU and sane Tx/Rx
> skb resource
> > management from single QP perspective.
>
> You should not do this.
>
> RX is several orders of magnitude more work than TX is. TX therefore
> should not be charged against the NAPI polling quota.
>
> Don't try to be different from other drivers unless you have detailed
> performance numbers from various situations (local TCP flows _and_
> routing) to justify it. :-)
>
> All NAPI drivers ignore TX work when considering NAPI polling quotas
> and you should too :-)
>
>
^ permalink raw reply
* Re: [PATCH net] net: Fix the rollback test in dev_change_name()
From: Eric Dumazet @ 2009-11-16 11:08 UTC (permalink / raw)
To: David Miller; +Cc: jarkao2, netdev
In-Reply-To: <20091116.024936.14048478.davem@davemloft.net>
David Miller a écrit :
> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Mon, 16 Nov 2009 09:30:24 +0000
>
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>>
>> net: Fix the rollback test in dev_change_name()
>>
>> In dev_change_name() an err variable is used for storing the original
>> call_netdevice_notifiers() errno (negative) and testing for a rollback
>> error later, but the test for non-zero is wrong, because the err might
>> have positive value as well - from dev_alloc_name(). It means the
>> rollback for a netdevice with a number > 0 will never happen. (The err
>> test is reordered btw. to make it more readable.)
>>
>> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
>
> Ok.
>
> Eric please give your signoff and I'll put this where it needs
> to go.
>
I finaly understood why I got stuck on this one : I thought dev_alloc_name()
was returning 0 in case of success. The test was thus realy obscure for me.
So Jarek patch is pretty clear now I saw the light !
Thanks
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [net-next] bnx2x: Handle Rx and Tx together in NAPI
From: David Miller @ 2009-11-16 11:05 UTC (permalink / raw)
To: B05799; +Cc: vladz, netdev, eilong
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B950BFF@zin33exm22.fsl.freescale.net>
From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
Date: Mon, 16 Nov 2009 16:33:56 +0530
> I was talking about an independent napi routine for cleaning tx ring, I
> do not want to mix the rx and tx clean ring processes.
But you absolutely should do this, it will give optimal performance.
^ permalink raw reply
* RE: [net-next] bnx2x: Handle Rx and Tx together in NAPI
From: Kumar Gopalpet-B05799 @ 2009-11-16 11:03 UTC (permalink / raw)
To: David Miller; +Cc: vladz, netdev, eilong
In-Reply-To: <20091116.024130.156214496.davem@davemloft.net>
>> Can we actually introduce NAPI mechanism for cleaning TX ring ??
>
>You really should if you can.
>
>Preferably you should combine it with RX work in a shared NAPI context
>(1 TX queue + 1 RX queue per NAPI context, for example), doing
>the TX reclaim first in your ->poll() routine, before the RX
>processing, because this TX reclaim provides freshly freed up
>SKBs for RX work that generates responses (TCP ACKs, etc.)
>
I was talking about an independent napi routine for cleaning tx ring, I
do not want to mix the rx and tx clean ring processes.
--
Thanks
Sandee
^ permalink raw reply
* Re: [PATCH 2/2] act_mirred: optimization
From: David Miller @ 2009-11-16 10:58 UTC (permalink / raw)
To: xiaosuo; +Cc: hadi, shemminger, netdev
In-Reply-To: <20091116.024839.257258321.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 16 Nov 2009 02:48:39 -0800 (PST)
> From: Changli Gao <xiaosuo@gmail.com>
> Date: Mon, 16 Nov 2009 17:53:29 +0800
>
>> act_mirred: optimization.
>>
>> move checking if eaction is valid in tcf_mirred_init()
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
>
> Also applied, thank you.
Nevermind, you're NOT TESTING the patches you are posting:
net/sched/act_mirred.c: In function ‘tcf_mirred’:
net/sched/act_mirred.c:168: error: label ‘out’ used but not defined
net/sched/act_mirred.c:158: warning: unused variable ‘err’
net/sched/act_mirred.c:158: warning: unused variable ‘retval’
make[2]: *** [net/sched/act_mirred.o] Error 1
make[1]: *** [net/sched] Error 2
make[1]: *** Waiting for unfinished jobs....
I'm thus reverting both changes.
Don't submit changes which are untested, it wastes my time.
^ permalink raw reply
* Re: [PATCH net] net: Fix the rollback test in dev_change_name()
From: David Miller @ 2009-11-16 10:49 UTC (permalink / raw)
To: jarkao2; +Cc: eric.dumazet, netdev
In-Reply-To: <20091116093024.GA13115@ff.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Mon, 16 Nov 2009 09:30:24 +0000
> From: Eric Dumazet <eric.dumazet@gmail.com>
>
> net: Fix the rollback test in dev_change_name()
>
> In dev_change_name() an err variable is used for storing the original
> call_netdevice_notifiers() errno (negative) and testing for a rollback
> error later, but the test for non-zero is wrong, because the err might
> have positive value as well - from dev_alloc_name(). It means the
> rollback for a netdevice with a number > 0 will never happen. (The err
> test is reordered btw. to make it more readable.)
>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
Ok.
Eric please give your signoff and I'll put this where it needs
to go.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] act_mirred: optimization
From: David Miller @ 2009-11-16 10:48 UTC (permalink / raw)
To: xiaosuo; +Cc: hadi, shemminger, netdev
In-Reply-To: <412e6f7f0911160153g31d5eado7c5569d9e95f7d01@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Mon, 16 Nov 2009 17:53:29 +0800
> act_mirred: optimization.
>
> move checking if eaction is valid in tcf_mirred_init()
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Also applied, thank you.
^ permalink raw reply
* Re: [PATCH 1/2] act_mirred: cleanup
From: David Miller @ 2009-11-16 10:48 UTC (permalink / raw)
To: hadi; +Cc: xiaosuo, shemminger, netdev
In-Reply-To: <1258363479.3251.25.camel@bigi>
From: jamal <hadi@cyberus.ca>
Date: Mon, 16 Nov 2009 04:24:39 -0500
> On Mon, 2009-11-16 at 16:33 +0800, Changli Gao wrote:
>> act_mirred: cleanup
>>
>> 1. don't let go back using goto.
>> 2. don't call skb_act_clone() until it is necessary.
>> 3. one exit of the critical context.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied.
^ permalink raw reply
* Re: [net-next] bnx2x: Handle Rx and Tx together in NAPI
From: David Miller @ 2009-11-16 10:41 UTC (permalink / raw)
To: B05799; +Cc: vladz, netdev, eilong
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B950BEF@zin33exm22.fsl.freescale.net>
From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
Date: Mon, 16 Nov 2009 16:02:04 +0530
> Can we actually introduce NAPI mechanism for cleaning TX ring ??
You really should if you can.
Preferably you should combine it with RX work in a shared NAPI context
(1 TX queue + 1 RX queue per NAPI context, for example), doing the TX
reclaim first in your ->poll() routine, before the RX processing,
because this TX reclaim provides freshly freed up SKBs for RX work
that generates responses (TCP ACKs, etc.)
^ permalink raw reply
* Re: [patch 4/5] [PATCH] qeth: rework TSO functions
From: David Miller @ 2009-11-16 10:36 UTC (permalink / raw)
To: blaschka; +Cc: netdev, linux-s390
In-Reply-To: <4B00F81D.8090106@linux.vnet.ibm.com>
From: Frank Blaschka <blaschka@linux.vnet.ibm.com>
Date: Mon, 16 Nov 2009 07:58:37 +0100
> I did not add any new sysfs knobs for TSO. The old one was just moved
> from the core part of the driver to the L3 discipline. I know ethtool
> is the way to configure TSO and I would be happy to drop sysfs off, but
> we have to keep this legacy interface because of our customers and
> distributors. If you say there is no way to keep it let me know and I
> will rework the patch.
Ok, if it's always been there :-/ It never should have been added
in the first place.
I'll add these patches to net-next-2.6, thanks.
^ permalink raw reply
* RE: [net-next] bnx2x: Handle Rx and Tx together in NAPI
From: Kumar Gopalpet-B05799 @ 2009-11-16 10:32 UTC (permalink / raw)
To: David Miller, vladz; +Cc: netdev, eilong
In-Reply-To: <20091116.022012.81633492.davem@davemloft.net>
>From: "Vladislav Zolotarov" <vladz@broadcom.com>
>Date: Mon, 16 Nov 2009 12:01:09 +0200
>
>> - Limit Tx work done in one iteration by the same number
>of packets
>> as Rx in order to ensure both fair work load balancing relatively to
>> other devices scheduled for NAPI on the local CPU and sane Tx/Rx skb
>> resource management from single QP perspective.
>
>You should not do this.
Can we actually introduce NAPI mechanism for cleaning TX ring ??
>RX is several orders of magnitude more work than TX is. TX
>therefore should not be charged against the NAPI polling quota.
>
>Don't try to be different from other drivers unless you have
>detailed performance numbers from various situations (local
>TCP flows _and_
>routing) to justify it. :-)
>
I tried (I am talking about gianfar driver) to introduce napi for
cleaning tx ring (similar to rx napi mechanism ) and found that it
actually improves performance for bi-directioanl flow on an SMP system
(performance is abt 1.6 times).
If introducing napi mechansim for tx is logical then I will send out an
RFC patch
>All NAPI drivers ignore TX work when considering NAPI polling
>quotas and you should too :-)
>--
--
Thanks
Sandeep
^ permalink raw reply
* Re: [PATCH 2/2] act_mirred: optimization
From: jamal @ 2009-11-16 10:24 UTC (permalink / raw)
To: David Miller; +Cc: xiaosuo, shemminger, netdev
In-Reply-To: <20091116.022144.203823073.davem@davemloft.net>
On Mon, 2009-11-16 at 02:21 -0800, David Miller wrote:
> From: jamal <hadi@cyberus.ca>
> Date: Mon, 16 Nov 2009 05:06:30 -0500
> > One indent too many?
>
> It's actually fixing some stray space characters into a real proper
> tab character.
good enough for me then.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] net/can: add driver for mscan family & mpc52xx_mscan
From: Wolfram Sang @ 2009-11-16 10:24 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Grant Likely, netdev-u79uwXL29TY76Z2rM5mHXA, David Miller,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
linuxppc-dev-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <4B0110D5.6010405-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1209 bytes --]
Hi Wolfgang,
On Mon, Nov 16, 2009 at 09:44:05AM +0100, Wolfgang Grandegger wrote:
> Hi Wolfram,
>
> thanks for pushing this driver to mainline. I think you should also add
> a CC to the Devicetree-discuss ML.
thank you very much for your review! I agree with nearly all of your points and will
send an update today. The only thing I have doubts about is removing those lines:
> +MODULE_AUTHOR("Andrey Volkov <avolkov-ppI4tVfbJvJWk0Htik3J/w@public.gmane.org>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("CAN port driver for a MSCAN based chips");
I looked around in the kernel sources and found that they are often present in
generic modules, even if they can't be used without a wrapper (examples are all
files in drivers/i2c/algos or drivers/net/wireless/iwlwifi/iwl-core.c). As I'm
also a bit anxious to fiddle with other people's authorship, I'd prefer to keep
them.
Finally, I'll also try to test suspend/resume, but I have to find out if it is
supported on that board in general.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ 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