* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 21:31 UTC (permalink / raw)
To: Thomas Graf; +Cc: kaber, netdev, David Miller
In-Reply-To: <20060630211043.GO14627@postel.suug.ch>
On Fri, 2006-30-06 at 23:10 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-30 16:54
> > I agree - and i try hard to document but at times there's too much
> > and a line needs to be drawn.
> > As an example:
> > the eth->ifb->ifb case though is a very corner case. All the IMQ types
> > need to only redirect to one ifb; while i test it ive always seen the
> > test as more of a boundary check than a useful setup.
>
> Maybe you should just start by explaining why it doesn't work,
> your original explanation doesn't make much sense.
>
Better to explain the reason for ifb first:
ifb exists initially as a replacement for IMQ.
1) qdiscs/policies that are per device as opposed to system wide.
This now allows for sharing.
2) Allows for queueing incoming traffic for shaping instead of
dropping.
In other wise, the main use is for multiple devices to redirect to it.
Main desire is not for it to redirect to any other ifb device or eth
devices. I actually tried to get it to do that, but run into issues
of complexity and and came up with decision to drop instead of killing
the machine.
Other than that, it can redirect to any other devices - but may still
not be meaningful.
I have been thinking of Herberts change of qdisc_is_running and this may
help actually.
> > And Thomas: I do keep notebooks ;-> I doodle about everything, they dont
> > all fit in my knapsack anymore so sometimes when i say i will go and
> > refer to my notes, it is real.
>
> It's plain arrogant to rely code understanding on information that
> is not available to others. It makes everyone being dependant on
> you, very nice.
>
I try hard to document more than many many people. I give tutorials, I
write papers when time allows, I spend time responding to emails. And i
do it all for the love of the game.
But lets look at the other side of the coin:
Dont you think it is polite to ask when something is not clear instead
of making assumptions?
> To put it in another way, if you would do your job right when
> writing the code, contacting or CCing you upon changes would
> be only of a formal matter since the code is understandable and
> the intent is clear or documented.
I wish I could achieve that. I dont think theres any piece of code that
reaches those standards in the kernel actually. And if theres a piece of
code that achieves that it should be emulated. Most of the times, things
that are hard are not about the code but about issues like algorithmics,
embedded policies etc (I think you are saying the same).
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 21:35 UTC (permalink / raw)
To: Thomas Graf; +Cc: Patrick McHardy, David Miller, netdev
In-Reply-To: <20060630212047.GP14627@postel.suug.ch>
On Fri, 2006-30-06 at 23:20 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-30 17:09
> > the ref inside the else below after changing input_dev
>
> A non-existant iif is already equivalent to !iif since it jumps
> into the same branch.
I thought 0 was a valid iif as Ben G was pointing - if it is not, you
are right.
> Grabing a reference is completely pointless,
> the netdevice represented by skb->iif is at this point until the
> packet gets queued covered by a reference taken in netif_rx().
You have to consider that this could happen at both ingress and egress.
cheers,
jamal
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: jamal @ 2006-06-30 21:51 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Sam Vilain, Herbert Poetzl, viro, devel, dev, Andrew Morton, clg,
serue, netdev, linux-kernel, Daniel Lezcano, Ben Greear,
Dave Hansen, Alexey Kuznetsov, Andrey Savochkin
In-Reply-To: <m13bdmbj1b.fsf@ebiederm.dsl.xmission.com>
On Fri, 2006-30-06 at 12:22 -0600, Eric W. Biederman wrote:
>
> Anyway Jamal can you see the problem the aliases present to the implementation?
>
I think more than anything i may have a different view of things and no
code ;-> And you are trying to restore order in the discussion - so my
wild ideas dont help. If you guys have a meeting somewhere like this
coming OLS I will come over and disrupt your meeting ;-> I actually have
attempted to implement things like virtual routers but you guys seem way
ahead of anywhere i was.
cheers,
jamal
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Andrew Morton @ 2006-06-30 22:50 UTC (permalink / raw)
To: Shailabh Nagar
Cc: nagar, pj, Valdis.Kletnieks, jlan, balbir, csturtiv, linux-kernel,
hadi, netdev
In-Reply-To: <44A5770F.3080206@watson.ibm.com>
Shailabh Nagar <nagar@watson.ibm.com> wrote:
>
> +/*
> + * Per-task exit data sent from the kernel to user space
> + * is tagged by an id based on grouping of cpus.
> + *
> + * If userspace specifies a non-zero P as the nl_pid field of
> + * the sockaddr_nl structure while binding to a netlink socket,
> + * it will receive exit data from threads that exited on cpus in the range
> + *
> + * [(P-1)*Y, P*Y-1]
> + *
> + * where Y = TASKSTATS_CPUS_PER_SET
> + * i.e. if TASKSTATS_CPUS_PER_SET is 16,
> + * to listen to data from cpus 0..15, specify P=1
> + * for cpus 16..32, specify P=2 etc.
> + *
> + * To listen to data from all cpus, userspace should use P=0
> + */
> +
> +#define TASKSTATS_CPUS_PER_SET 16
The constant is unpleasant.
If we're going to abuse nl_pid then how about we design things so that
nl_pid is treated as two 16-bit words - one word is the start CPU and the
other word is the end cpu?
Or, if a 65536-CPU limit is too scary, make the bottom 8 bits of nl_pid be
the number of CPUS (ie: TASKSTATS_CPUS_PER_SET) and the top 24 bits is the
starting CPU.
<avoids mentioning nl_pad>
It'd be better to use a cpumask, of course..
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Andrew Morton @ 2006-06-30 22:56 UTC (permalink / raw)
To: Shailabh Nagar
Cc: pj, Valdis.Kletnieks, jlan, balbir, csturtiv, linux-kernel, hadi,
netdev
In-Reply-To: <44A57310.3010208@watson.ibm.com>
Shailabh Nagar <nagar@watson.ibm.com> wrote:
>
> Based on previous discussions, the above solutions can be expanded/modified to:
>
> a) allow userspace to listen to a group of cpus instead of all. Multiple
> collection daemons can distribute the load as you pointed out. Doing collection
> by cpu groups rather than individual cpus reduces the aggregation burden on
> userspace (and scales better with NR_CPUS)
>
> b) do flow control on the kernel send side. This can involve buffering and sending
> later (to handle bursty case) or dropping (to handle sustained load) as pointed out
> by you, Jamal in other threads.
>
> c) increase receiver's socket buffer. This can and should always be done but no
> involvement needed.
>
>
> With regards to taskstats changes to handle the problem and its impact on userspace
> visible changes,
>
> a) will change userspace
> b) will be transparent.
> c) is immaterial going forward (except perhaps as a change in Documentation)
>
>
> I'm sending a patch that demonstrates how a) can be done quite simply
> and a patch for b) is in progress.
>
> If the approach suggested in patch a) is acceptable (and I'll provide the testing, stability
> results once comments on it are largely over), could taskstats acceptance in 2.6.18 go ahead
> and patch b) be added later (solution outline has already been provided and a prelim patch should
> be out by eod)
Throwing more CPUs at the problem makes heaps of sense.
It's not necessarily a userspace-incompatible change. As long as userspace
sets nl_pid to 0x00000000, future kernel revisions can treat that as "all
CPUs". Or userspace can be forward-compatible by setting nl_pid to
0xffff0000, or whatever.
^ permalink raw reply
* [PATCH] NET: Fix ipv6 GSO payload length
From: Michael Chan @ 2006-06-30 22:56 UTC (permalink / raw)
To: davem, herbert; +Cc: netdev
Fix ipv6 GSO payload length calculation.
The ipv6 payload length excludes the ipv6 base header length and so
must be subtracted.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 25f8bf8..2d622d1 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -112,7 +112,8 @@ unlock:
for (skb = segs; skb; skb = skb->next) {
ipv6h = skb->nh.ipv6h;
- ipv6h->payload_len = htons(skb->len - skb->mac_len);
+ ipv6h->payload_len = htons(skb->len - skb->mac_len -
+ sizeof(*ipv6h));
}
out:
^ permalink raw reply related
* Re: RDMA will be reverted
From: Tom Tucker @ 2006-06-30 23:01 UTC (permalink / raw)
To: David Miller; +Cc: rdreier, netdev, akpm
In-Reply-To: <20060630.141658.34759102.davem@davemloft.net>
On Fri, 2006-06-30 at 14:16 -0700, David Miller wrote:
> The TOE folks have tried to submit their hooks and drivers
> on several occaisions, and we've rejected it every time.
iWARP != TOE
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Thomas Graf @ 2006-06-30 23:22 UTC (permalink / raw)
To: jamal; +Cc: Patrick McHardy, David Miller, netdev
In-Reply-To: <1151703305.5270.311.camel@jzny2>
This is boring, I reversed everything to not change any semantics and
you still complain.
* jamal <hadi@cyberus.ca> 2006-06-30 17:35
> On Fri, 2006-30-06 at 23:20 +0200, Thomas Graf wrote:
> > * jamal <hadi@cyberus.ca> 2006-06-30 17:09
> > > the ref inside the else below after changing input_dev
> >
> > A non-existant iif is already equivalent to !iif since it jumps
> > into the same branch.
>
> I thought 0 was a valid iif as Ben G was pointing - if it is not, you
> are right.
No, 1 ist the first valid ifindex, see dev_new_index().
> > Grabing a reference is completely pointless,
> > the netdevice represented by skb->iif is at this point until the
> > packet gets queued covered by a reference taken in netif_rx().
>
> You have to consider that this could happen at both ingress and egress.
Just think for a second, do you expect the device the packet will
be leaving at to disappear?
^ permalink raw reply
* [PATCH] IOAT: fix header file kernel-doc
From: Randy.Dunlap @ 2006-06-30 23:28 UTC (permalink / raw)
To: netdev; +Cc: davem, akpm, christopher.leech
From: Randy Dunlap <rdunlap@xenotime.net>
Fix kernel-doc problems in include/linux/dmaengine.h:
- add some fields/parameters
- expand some descriptions
- fix typos
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
include/linux/dmaengine.h | 43 +++++++++++++++++++++++++------------------
1 files changed, 25 insertions(+), 18 deletions(-)
--- linux-2617-g13.orig/include/linux/dmaengine.h
+++ linux-2617-g13/include/linux/dmaengine.h
@@ -44,7 +44,7 @@ enum dma_event {
};
/**
- * typedef dma_cookie_t
+ * typedef dma_cookie_t - an opaque DMA cookie
*
* if dma_cookie_t is >0 it's a DMA request cookie, <0 it's an error code
*/
@@ -80,14 +80,14 @@ struct dma_chan_percpu {
/**
* struct dma_chan - devices supply DMA channels, clients use them
- * @client: ptr to the client user of this chan, will be NULL when unused
- * @device: ptr to the dma device who supplies this channel, always !NULL
+ * @client: ptr to the client user of this chan, will be %NULL when unused
+ * @device: ptr to the dma device who supplies this channel, always !%NULL
* @cookie: last cookie value returned to client
- * @chan_id:
- * @class_dev:
+ * @chan_id: channel ID for sysfs
+ * @class_dev: class device for sysfs
* @refcount: kref, used in "bigref" slow-mode
- * @slow_ref:
- * @rcu:
+ * @slow_ref: indicates that the DMA channel is free
+ * @rcu: the DMA channel's RCU head
* @client_node: used to add this to the client chan list
* @device_node: used to add this to the device chan list
* @local: per-cpu pointer to a struct dma_chan_percpu
@@ -162,10 +162,17 @@ struct dma_client {
* @chancnt: how many DMA channels are supported
* @channels: the list of struct dma_chan
* @global_node: list_head for global dma_device_list
- * @refcount:
- * @done:
- * @dev_id:
- * Other func ptrs: used to make use of this device's capabilities
+ * @refcount: reference count
+ * @done: IO completion struct
+ * @dev_id: unique device ID
+ * @device_alloc_chan_resources: allocate resources and return the
+ * number of allocated descriptors
+ * @device_free_chan_resources: release DMA channel's resources
+ * @device_memcpy_buf_to_buf: memcpy buf pointer to buf pointer
+ * @device_memcpy_buf_to_pg: memcpy buf pointer to struct page
+ * @device_memcpy_pg_to_pg: memcpy struct page/offset to struct page/offset
+ * @device_memcpy_complete: poll the status of an IOAT DMA transaction
+ * @device_memcpy_issue_pending: push appended descriptors to hardware
*/
struct dma_device {
@@ -211,7 +218,7 @@ void dma_async_client_chan_request(struc
* Both @dest and @src must be mappable to a bus address according to the
* DMA mapping API rules for streaming mappings.
* Both @dest and @src must stay memory resident (kernel memory or locked
- * user space pages)
+ * user space pages).
*/
static inline dma_cookie_t dma_async_memcpy_buf_to_buf(struct dma_chan *chan,
void *dest, void *src, size_t len)
@@ -225,7 +232,7 @@ static inline dma_cookie_t dma_async_mem
}
/**
- * dma_async_memcpy_buf_to_pg - offloaded copy
+ * dma_async_memcpy_buf_to_pg - offloaded copy from address to page
* @chan: DMA channel to offload copy to
* @page: destination page
* @offset: offset in page to copy to
@@ -250,18 +257,18 @@ static inline dma_cookie_t dma_async_mem
}
/**
- * dma_async_memcpy_buf_to_pg - offloaded copy
+ * dma_async_memcpy_pg_to_pg - offloaded copy from page to page
* @chan: DMA channel to offload copy to
- * @dest_page: destination page
+ * @dest_pg: destination page
* @dest_off: offset in page to copy to
- * @src_page: source page
+ * @src_pg: source page
* @src_off: offset in page to copy from
* @len: length
*
* Both @dest_page/@dest_off and @src_page/@src_off must be mappable to a bus
* address according to the DMA mapping API rules for streaming mappings.
* Both @dest_page/@dest_off and @src_page/@src_off must stay memory resident
- * (kernel memory or locked user space pages)
+ * (kernel memory or locked user space pages).
*/
static inline dma_cookie_t dma_async_memcpy_pg_to_pg(struct dma_chan *chan,
struct page *dest_pg, unsigned int dest_off, struct page *src_pg,
@@ -278,7 +285,7 @@ static inline dma_cookie_t dma_async_mem
/**
* dma_async_memcpy_issue_pending - flush pending copies to HW
- * @chan:
+ * @chan: target DMA channel
*
* This allows drivers to push copies to HW in batches,
* reducing MMIO writes where possible.
---
^ permalink raw reply
* [PATCH] tg3: Add ipv6 TSO feature
From: Michael Chan @ 2006-06-30 23:35 UTC (permalink / raw)
To: davem; +Cc: netdev
Enable ipv6 TSO feature on chips that support it.
Update version to 3.61.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 47c96fc..b992c0a 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -69,8 +69,8 @@
#define DRV_MODULE_NAME "tg3"
#define PFX DRV_MODULE_NAME ": "
-#define DRV_MODULE_VERSION "3.61"
-#define DRV_MODULE_RELDATE "June 29, 2006"
+#define DRV_MODULE_VERSION "3.62"
+#define DRV_MODULE_RELDATE "June 30, 2006"
#define TG3_DEF_MAC_MODE 0
#define TG3_DEF_RX_MODE 0
@@ -3799,18 +3799,24 @@ static int tg3_start_xmit(struct sk_buff
goto out_unlock;
}
- tcp_opt_len = ((skb->h.th->doff - 5) * 4);
- ip_tcp_len = (skb->nh.iph->ihl * 4) + sizeof(struct tcphdr);
+ if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6)
+ mss |= (skb_headlen(skb) - ETH_HLEN) << 9;
+ else {
+ tcp_opt_len = ((skb->h.th->doff - 5) * 4);
+ ip_tcp_len = (skb->nh.iph->ihl * 4) +
+ sizeof(struct tcphdr);
+
+ skb->nh.iph->check = 0;
+ skb->nh.iph->tot_len = htons(mss + ip_tcp_len +
+ tcp_opt_len);
+ mss |= (ip_tcp_len + tcp_opt_len) << 9;
+ }
base_flags |= (TXD_FLAG_CPU_PRE_DMA |
TXD_FLAG_CPU_POST_DMA);
- skb->nh.iph->check = 0;
- skb->nh.iph->tot_len = htons(mss + ip_tcp_len + tcp_opt_len);
-
skb->h.th->check = 0;
- mss |= (ip_tcp_len + tcp_opt_len) << 9;
}
else if (skb->ip_summed == CHECKSUM_HW)
base_flags |= TXD_FLAG_TCPUDP_CSUM;
@@ -7888,6 +7894,12 @@ static int tg3_set_tso(struct net_device
return -EINVAL;
return 0;
}
+ if (tp->tg3_flags2 & TG3_FLG2_HW_TSO_2) {
+ if (value)
+ dev->features |= NETIF_F_TSO6;
+ else
+ dev->features &= ~NETIF_F_TSO6;
+ }
return ethtool_op_set_tso(dev, value);
}
#endif
@@ -11508,8 +11520,11 @@ static int __devinit tg3_init_one(struct
* Firmware TSO on older chips gives lower performance, so it
* is off by default, but can be enabled using ethtool.
*/
- if (tp->tg3_flags2 & TG3_FLG2_HW_TSO)
+ if (tp->tg3_flags2 & TG3_FLG2_HW_TSO) {
dev->features |= NETIF_F_TSO;
+ if (tp->tg3_flags2 & TG3_FLG2_HW_TSO_2)
+ dev->features |= NETIF_F_TSO6;
+ }
#endif
^ permalink raw reply related
* Re: jumbo frames and memory fragmentation
From: Chris Friesen @ 2006-06-30 23:35 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: Herbert Xu, netdev
In-Reply-To: <20060630184820.GA9558@2ka.mipt.ru>
Evgeniy Polyakov wrote:
> It definitely will.
> Packet split in hardware means separating data and headers into
> different pages in different reads, while software page split means that
> skb has a list of fragments where part of the packet will be DMAed, so
> jumbo frame will be converted into several pages.
Maybe I'm looking at the wrong code then. Can you point me to where
this "software page split" is handled?
Chris
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Thomas Graf @ 2006-06-30 23:45 UTC (permalink / raw)
To: jamal; +Cc: kaber, netdev, David Miller
In-Reply-To: <1151703097.5270.307.camel@jzny2>
* jamal <hadi@cyberus.ca> 2006-06-30 17:31
> Better to explain the reason for ifb first:
> ifb exists initially as a replacement for IMQ.
> 1) qdiscs/policies that are per device as opposed to system wide.
> This now allows for sharing.
>
> 2) Allows for queueing incoming traffic for shaping instead of
> dropping.
>
> In other wise, the main use is for multiple devices to redirect to it.
> Main desire is not for it to redirect to any other ifb device or eth
> devices. I actually tried to get it to do that, but run into issues
> of complexity and and came up with decision to drop instead of killing
> the machine.
> Other than that, it can redirect to any other devices - but may still
> not be meaningful.
Last time I'm asking. Why are packets dropped? You mentioned tc_verd
is set to 0 leading to a invalid from verdict. Fact is that the
from verdict is set to a meaningful value again at dev_queue_xmit()
or ing_filter() so ifb_xmit() only sees valid values. tx locks of
individual ifb devices are independant, why would it deadlock? Where
is the packet exactly dropped?
> I have been thinking of Herberts change of qdisc_is_running and this may
> help actually.
Help on what?
^ permalink raw reply
* RE: [1/4] [IPV6]: Remove redundant length check on input
From: Ananda Raju @ 2006-06-30 23:44 UTC (permalink / raw)
To: David Miller, herbert; +Cc: netdev
Hi,
I tested the patch, and TSO over ipv6 is working fine. But TSO disable
not working for IPv6.
I tried the from tree /pub/scm/linux/kernel/git/davem/net-2.6
Ananda
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Friday, June 30, 2006 2:20 PM
To: herbert@gondor.apana.org.au
Cc: Ananda Raju; netdev@vger.kernel.org
Subject: Re: [1/4] [IPV6]: Remove redundant length check on input
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 30 Jun 2006 15:42:09 +1000
> I've added GSO for TCPv6 and updated Ananda's patch. Please note that
> the following patches have only been compile-tested.
I applied this and pushed it to Linus, let's cross our fingers :)
^ permalink raw reply
* RE: [1/4] [IPV6]: Remove redundant length check on input
From: Michael Chan @ 2006-06-30 23:52 UTC (permalink / raw)
To: Ananda Raju; +Cc: David Miller, herbert, netdev
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7793A4C8@nekter>
On Fri, 2006-06-30 at 19:44 -0400, Ananda Raju wrote:
> Hi,
>
> I tested the patch, and TSO over ipv6 is working fine. But TSO disable
> not working for IPv6.
>
You need to clear NETIF_F_TSO6 in dev->features to disable ipv6 TSO.
^ permalink raw reply
* RE: [1/4] [IPV6]: Remove redundant length check on input
From: Ananda Raju @ 2006-06-30 23:55 UTC (permalink / raw)
To: Michael Chan; +Cc: David Miller, herbert, netdev
True, I am referring to "ethtool -K ethX tso off"
ethtool_op_set_tso() won't clear NETIF_F_TSO6 for ethtool -K ethX tso
off
Ananda
-----Original Message-----
From: Michael Chan [mailto:mchan@broadcom.com]
Sent: Friday, June 30, 2006 4:53 PM
To: Ananda Raju
Cc: David Miller; herbert@gondor.apana.org.au; netdev@vger.kernel.org
Subject: RE: [1/4] [IPV6]: Remove redundant length check on input
On Fri, 2006-06-30 at 19:44 -0400, Ananda Raju wrote:
> Hi,
>
> I tested the patch, and TSO over ipv6 is working fine. But TSO disable
> not working for IPv6.
>
You need to clear NETIF_F_TSO6 in dev->features to disable ipv6 TSO.
^ permalink raw reply
* [PATCH] IOAT: fix kernel-doc in source files
From: Randy.Dunlap @ 2006-07-01 0:01 UTC (permalink / raw)
To: netdev; +Cc: christopher.leech, akpm, davem
From: Randy Dunlap <rdunlap@xenotime.net>
Fix kernel-doc warnings in drivers/dma/:
- use correct function & parameter names
- add descriptions where omitted
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
drivers/dma/dmaengine.c | 20 ++++++++++++--------
drivers/dma/ioatdma.c | 8 +++++---
2 files changed, 17 insertions(+), 11 deletions(-)
--- linux-2617-g13.orig/drivers/dma/dmaengine.c
+++ linux-2617-g13/drivers/dma/dmaengine.c
@@ -166,8 +166,8 @@ static struct dma_chan *dma_client_chan_
}
/**
- * dma_client_chan_free - release a DMA channel
- * @chan: &dma_chan
+ * dma_chan_cleanup - release a DMA channel's resources
+ * @kref: kernel reference structure that contains the DMA channel device
*/
void dma_chan_cleanup(struct kref *kref)
{
@@ -199,7 +199,7 @@ static void dma_client_chan_free(struct
* dma_chans_rebalance - reallocate channels to clients
*
* When the number of DMA channel in the system changes,
- * channels need to be rebalanced among clients
+ * channels need to be rebalanced among clients.
*/
static void dma_chans_rebalance(void)
{
@@ -264,7 +264,7 @@ struct dma_client *dma_async_client_regi
/**
* dma_async_client_unregister - unregister a client and free the &dma_client
- * @client:
+ * @client: &dma_client to free
*
* Force frees any allocated DMA channels, frees the &dma_client memory
*/
@@ -306,7 +306,7 @@ void dma_async_client_chan_request(struc
}
/**
- * dma_async_device_register -
+ * dma_async_device_register - registers DMA devices found
* @device: &dma_device
*/
int dma_async_device_register(struct dma_device *device)
@@ -348,8 +348,8 @@ int dma_async_device_register(struct dma
}
/**
- * dma_async_device_unregister -
- * @device: &dma_device
+ * dma_async_device_cleanup - function called when all references are released
+ * @kref: kernel reference object
*/
static void dma_async_device_cleanup(struct kref *kref)
{
@@ -359,7 +359,11 @@ static void dma_async_device_cleanup(str
complete(&device->done);
}
-void dma_async_device_unregister(struct dma_device* device)
+/**
+ * dma_async_device_unregister - unregisters DMA devices
+ * @device: &dma_device
+ */
+void dma_async_device_unregister(struct dma_device *device)
{
struct dma_chan *chan;
unsigned long flags;
--- linux-2617-g13.orig/drivers/dma/ioatdma.c
+++ linux-2617-g13/drivers/dma/ioatdma.c
@@ -217,7 +217,7 @@ static void ioat_dma_free_chan_resources
/**
* do_ioat_dma_memcpy - actual function that initiates a IOAT DMA transaction
- * @chan: IOAT DMA channel handle
+ * @ioat_chan: IOAT DMA channel handle
* @dest: DMA destination address
* @src: DMA source address
* @len: transaction length in bytes
@@ -383,7 +383,7 @@ static dma_cookie_t ioat_dma_memcpy_buf_
* @dest_off: offset into that page
* @src_pg: pointer to the page to copy from
* @src_off: offset into that page
- * @len: transaction length in bytes. This is guaranteed to not make a copy
+ * @len: transaction length in bytes. This is guaranteed not to make a copy
* across a page boundary.
*/
@@ -407,7 +407,7 @@ static dma_cookie_t ioat_dma_memcpy_pg_t
}
/**
- * ioat_dma_memcpy_issue_pending - push potentially unrecognoized appended descriptors to hw
+ * ioat_dma_memcpy_issue_pending - push potentially unrecognized appended descriptors to hw
* @chan: DMA channel handle
*/
@@ -510,6 +510,8 @@ static void ioat_dma_memcpy_cleanup(stru
* ioat_dma_is_complete - poll the status of a IOAT DMA transaction
* @chan: IOAT DMA channel handle
* @cookie: DMA transaction identifier
+ * @done: if not %NULL, updated with last completed transaction
+ * @used: if not %NULL, updated with last used transaction
*/
static enum dma_status ioat_dma_is_complete(struct dma_chan *chan,
---
^ permalink raw reply
* Re: jumbo frames and memory fragmentation
From: Jesse Brandeburg @ 2006-07-01 0:04 UTC (permalink / raw)
To: Chris Friesen; +Cc: Evgeniy Polyakov, Herbert Xu, netdev
In-Reply-To: <44A5B546.3010606@nortel.com>
On 6/30/06, Chris Friesen <cfriesen@nortel.com> wrote:
> Evgeniy Polyakov wrote:
>
> > It definitely will.
> > Packet split in hardware means separating data and headers into
> > different pages in different reads, while software page split means that
> > skb has a list of fragments where part of the packet will be DMAed, so
> > jumbo frame will be converted into several pages.
>
> Maybe I'm looking at the wrong code then. Can you point me to where
> this "software page split" is handled?
You're right, it isn't supported for your hardware. to solve the
problem (I got this from mailing lists) you probably need to adjust
the /proc/sys/vm/min_free_kbytes
let us know if this helps for you.
^ permalink raw reply
* RE: [1/4] [IPV6]: Remove redundant length check on input
From: Michael Chan @ 2006-07-01 0:07 UTC (permalink / raw)
To: Ananda Raju; +Cc: David Miller, herbert, netdev
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7793A4CB@nekter>
On Fri, 2006-06-30 at 19:55 -0400, Ananda Raju wrote:
> True, I am referring to "ethtool -K ethX tso off"
> ethtool_op_set_tso() won't clear NETIF_F_TSO6 for ethtool -K ethX tso
> off
>
Instead of using ethtool_op_set_tso() in your ethtool_ops structure, you
can use a private function to set or clear any new bits such as
NETIF_F_TSO6 or NETIF_F_TSO_ECN.
^ permalink raw reply
* RE: [1/4] [IPV6]: Remove redundant length check on input
From: Ananda Raju @ 2006-07-01 0:08 UTC (permalink / raw)
To: Michael Chan; +Cc: David Miller, herbert, netdev
Sure, we will do that.
-----Original Message-----
From: Michael Chan [mailto:mchan@broadcom.com]
Sent: Friday, June 30, 2006 5:08 PM
To: Ananda Raju
Cc: David Miller; herbert@gondor.apana.org.au; netdev@vger.kernel.org
Subject: RE: [1/4] [IPV6]: Remove redundant length check on input
On Fri, 2006-06-30 at 19:55 -0400, Ananda Raju wrote:
> True, I am referring to "ethtool -K ethX tso off"
> ethtool_op_set_tso() won't clear NETIF_F_TSO6 for ethtool -K ethX tso
> off
>
Instead of using ethtool_op_set_tso() in your ethtool_ops structure, you
can use a private function to set or clear any new bits such as
NETIF_F_TSO6 or NETIF_F_TSO_ECN.
^ permalink raw reply
* Re: [PATCH] com20020_cs: more device support
From: Jeff Garzik @ 2006-07-01 0:32 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: akpm, linux, Netdev List
In-Reply-To: <200607010001.k6101HI9009640@hera.kernel.org>
For the nth time, drivers/net patches should at least be CC'd to netdev
and me.
Jeff
^ permalink raw reply
* Re: [PATCH] pcmcia: hostap_cs.c - 0xc00f,0x0000 conflicts with pcnet_cs
From: Jeff Garzik @ 2006-07-01 0:34 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, linux, Netdev List, John W. Linville
In-Reply-To: <200607010001.k610165k008843@hera.kernel.org>
Linux Kernel Mailing List wrote:
> commit fd99ddd0701385344eadaf2daa6abbc5fb086750
> tree 013d75048f086edfa7a89ac3f3301dde13017817
> parent 0db6095d4ff8918350797dfe299d572980e82fa0
> author Komuro <komurojun-mbn@nifty.com> Mon, 17 Apr 2006 21:41:21 +0900
> committer Dominik Brodowski <linux@dominikbrodowski.net> Fri, 30 Jun 2006 22:09:12 +0200
>
> [PATCH] pcmcia: hostap_cs.c - 0xc00f,0x0000 conflicts with pcnet_cs
>
> Comment out the ID 0xc00f,0x0000 in hostap_cs.c, as it conflicts with the
> pcnet_cs driver.
>
> Signed-off-by: komurojun-mbn@nifty.com
> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
>
> drivers/net/wireless/hostap/hostap_cs.c | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless stuff should go through netdev and John Linville.
I'm going to go out on a limb, and guess that Linville never saw this patch?
Jeff
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Eric W. Biederman @ 2006-07-01 0:50 UTC (permalink / raw)
To: hadi
Cc: Sam Vilain, Herbert Poetzl, viro, devel, dev, Andrew Morton, clg,
serue, netdev, linux-kernel, Daniel Lezcano, Ben Greear,
Dave Hansen, Alexey Kuznetsov, Andrey Savochkin
In-Reply-To: <1151704319.5270.317.camel@jzny2>
jamal <hadi@cyberus.ca> writes:
> On Fri, 2006-30-06 at 12:22 -0600, Eric W. Biederman wrote:
>
>>
>> Anyway Jamal can you see the problem the aliases present to the
> implementation?
>>
>
> I think more than anything i may have a different view of things and no
> code ;-> And you are trying to restore order in the discussion - so my
> wild ideas dont help. If you guys have a meeting somewhere like this
> coming OLS I will come over and disrupt your meeting ;-> I actually have
> attempted to implement things like virtual routers but you guys seem way
> ahead of anywhere i was.
Currently I think we have both a talk, and a BOFH at OLS plus probably
a little time at kernel summit.
Eric
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Shailabh Nagar @ 2006-07-01 2:20 UTC (permalink / raw)
To: Andrew Morton
Cc: pj, Valdis.Kletnieks, jlan, balbir, csturtiv, linux-kernel, hadi,
netdev
In-Reply-To: <20060630155030.5ea1faba.akpm@osdl.org>
Andrew Morton wrote:
>Shailabh Nagar <nagar@watson.ibm.com> wrote:
>
>
>>+/*
>>+ * Per-task exit data sent from the kernel to user space
>>+ * is tagged by an id based on grouping of cpus.
>>+ *
>>+ * If userspace specifies a non-zero P as the nl_pid field of
>>+ * the sockaddr_nl structure while binding to a netlink socket,
>>+ * it will receive exit data from threads that exited on cpus in the range
>>+ *
>>+ * [(P-1)*Y, P*Y-1]
>>+ *
>>+ * where Y = TASKSTATS_CPUS_PER_SET
>>+ * i.e. if TASKSTATS_CPUS_PER_SET is 16,
>>+ * to listen to data from cpus 0..15, specify P=1
>>+ * for cpus 16..32, specify P=2 etc.
>>+ *
>>+ * To listen to data from all cpus, userspace should use P=0
>>+ */
>>+
>>+#define TASKSTATS_CPUS_PER_SET 16
>>
>>
>
>The constant is unpleasant.
>
>
I was planning to make it configurable. But that would still not be as
flexible as below...
>If we're going to abuse nl_pid then how about we design things so that
>nl_pid is treated as two 16-bit words - one word is the start CPU and the
>other word is the end cpu?
>
>Or, if a 65536-CPU limit is too scary, make the bottom 8 bits of nl_pid be
>the number of CPUS (ie: TASKSTATS_CPUS_PER_SET) and the top 24 bits is the
>starting CPU.
>
><avoids mentioning nl_pad>
>
>It'd be better to use a cpumask, of course..
>
>
All these options mean each listener gets to pick a "custom" range of
cpus to listen on,
rather than choose one of pre-defined ranges (even if the pre-defined
ranges can change
by a configurable TASKSTATS_CPUS_PER_SET). Which means the kernel side
has to
figure out which of the listeners cpu range includes the currently
exiting task's cpu. To do
this, we'll need a callback from the binding of the netlink socket (so
taskstats can maintain
the cpu -> nl_pid mappings at any exit).
The current genetlink interface doesn't have that kind of flexibility
(though it can be added
I'm sure).
Seems a bit involved if the primary aim is to restrict the number of
cpus that one listener
wants to listen, rather than be able to pick which ones.
A configurable range won't suffice ?
--Shailabh
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-07-01 2:23 UTC (permalink / raw)
To: Thomas Graf; +Cc: netdev, David Miller, Patrick McHardy
In-Reply-To: <20060630232214.GQ14627@postel.suug.ch>
On Sat, 2006-01-07 at 01:22 +0200, Thomas Graf wrote:
> This is boring, I reversed everything to not change any semantics and
> you still complain.
>
You reversed a bug that you had introduced. Do you want me to review
this patch or not now? Be a little reasonable please.
> * jamal <hadi@cyberus.ca> 2006-06-30 17:35
> > > Grabing a reference is completely pointless,
> > > the netdevice represented by skb->iif is at this point until the
> > > packet gets queued covered by a reference taken in netif_rx().
> >
> > You have to consider that this could happen at both ingress and egress.
>
> Just think for a second, do you expect the device the packet will
> be leaving at to disappear?
I am not certain i understood then: Are we in the mode where the
refcount is not needed because chances are small that a device will
disappear? It seems to me after all this trouble that it may not be so
bad to refcount (I guess i meant refcount the device on input to the ifb
and decrement on the output).
As a note - and i am sure you know this:
The packet comes to the ifb and gets queued. It gets dequeued at a later
time and is sent off either to the ingress or egress. At any point
during the enq/deq the other device being referenced could
disappear. This is a lesser sin on ingress than it is on egress.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Patrick McHardy @ 2006-07-01 2:47 UTC (permalink / raw)
To: hadi; +Cc: David Miller, netdev, Thomas Graf
In-Reply-To: <1151697554.5270.241.camel@jzny2>
jamal wrote:
> On Fri, 2006-30-06 at 19:33 +0200, Patrick McHardy wrote:
>
>>Well, I thought I stay out of this, but since you mention me ..
>>
> I think you will add value to the discussion ;->
> Regardless, we need to settle these kind of issues so we can work better
> together. A while back i said was going to bring some of these issues at
> the next netconf - but since the discussion is happening already, lets
> do it here. Maybe we should take this discussion privately?
Whatever helps resolving this, feel free to take this private if you
feel like it. I think I already managed to get along with our
differences quite well, but it was a hard path. Having friends that
use the same discussion tactics may have helped :) Just to clarify what
I'm saying below, I like you a lot personally, this is purely
"a work thing".
>>I also had the feeling it has gotten easier working with you lately,
>
>
> The feeling is mutual.
>
>
>>but I can understand Thomas's pain, I had the same thoughts more than
>>once. Your code often does have an enormous amount of bugs and
>>whitespace and other stylistic problems and working with you can be
>>challenging for multiple reasons, for example having to go to endless,
>
>
> One thing is clear in my mind at least (and i have said it several
> times): I am not as good at the semantics as either yourself or Thomas
> or Dave or Acme etc but i have tons of other things that compensate for.
> Probably "not as good" is not the best description - rather my brain
> cells put less respect on the stylistic commas than they do on the
> message. Perhaps it's dylexsia or me trying to subconsciouly maximize my
> time. If you push me hard, however, i will get close to do just as a
> good job as you;-> Still, cant live without you guys!
I think the things you did and which I struggeled with were right
to do, but what I don't understand is why you can't do it right
yourself. Software development has a lot of unpleasant parts,
but ignoring them can't be the right answer. In a shared project,
you should always remember that if you're not doing the work, some
else will have to.
> I would describe the majority of the fixes you have sent against me to
> fall into the stylistic category and into fixing TheLinuxWay (i.e same
> bug in multiple places and files). This is not to say i am not at fault,
> or there havent been issues which made me wonder, but we may have
> different metrics of what bugs i would call my mom and say "Mom, I just
> fixed enormous amount of bugs".
> [As an example if you went hunting around the kernel, you will find a
> lot of things that dont totally conform to lindent rules. You could
> literally send 100s of patches].
> Perhaps it is the language usage that puts us at odds at times.
Sorry, absolutely not. The bugs I fixed were not just stylistic
things, although I still tried to take care of them where possible.
It was a huge number of bad bugs, even affecting kernels that didn't
even used the feature which introduced the bugs. As for "TheLinuxWay"
(I think I made my opinion on this clear already), cut-and-paste
of crappy code is not it. I'm always amazed how people can copy
crappy code without even thinking about it, when I copy code I usually
fix bugs in the code I copy _before_ doing so.
Language might of course still contribute to our misunderstandings.
>>often entirely pointless discussions for obvious fixes,
>
>
> You may see it that way - I dont and so when that happens it is not by
> any means to engage in a meaningless debate.
> The discussions are typically of the same nature as i just had with
> Thomas (just a simple one line change in ifb which looked very
> "obvious").
Sometimes you may be right, but despite all the lengthy discussions
we went through, I can't recall a single patch of mine that didn't
went in eventually. But OK, people are complaining about missing
clarification of intent, we're all sometimes guilty of that.
Still, starting a huge discussion about patches that clearly
move in the right direction like Thomas' one which started this
thread is frustrating to the submitter. Discussions about technical
matters should use technical, comprehensible arguments, and nothing
else. This basically means on of three things:
- Bad because it does ..
- Bad because this patch is better
- Applied
Vague expressions about "not good", "might be able to do better" or
"might create problems" without specification are not helpful as long
as they are vague. The point is: _show_ that the submitters argument
is wrong, and if it really is, that shouldn't be hard. This is
especially true if its not some random guy but someone familiar with
what he is changing. This thread is one of many examples.
> The way it goes is that there is a certain assumption made, and a
> solution is suggested in the form of a patch. Accepting such a patch
> (which i once in a while dont even get to see until it is in) means a
> lot of the other assumptions get invalidated and is followed by tons of
> "bug fixes". This has happened a few times to me. And once or twice i
> have bitched because i ended having to support some user for days with
> the wrong view.
Then the patch wasn't reviewed carefully enough. If assumptions get
invalidated, they need to be taken care of at the same time. It can
happen, and sometimes it even is intended (in case of not so well
understood code). But usually it is not and it is simply a bug,
and the submitter is guilty of not beeing careful enough.
>>especially if you're already pissed by noticing 50 bugs at once.
>
>
> I dont get agitated by 100 patches which fix stylistic issues or real
> bugs - although i would have preferred to see the non-obvious first
> before they go in just in case or at least CCed on submission.
> Where i get irritated, depending on how my day is going: when i see even
> a single patch laded with implicit insults. It comes out to me as
> unnecessary arrogance and immaturity. It may not be intentional use of
> language, but thats how it comes out.
Well, I admit that the insults (in the form of a description of all
the possible bugs, which is not really an insult) are sometimes
intentional, but usually only after I'm already really pissed by
having to take care of an enormous amount of somebody elses crap.
I think that is understandable human behaviour.
>>The reason why you
>>might be able to work better with Herbert is IMO that he usually
>>doesn't touch what you seem to feel is "your area".
>
>
> I think it's the maturity approach perhaps. With Herbert, it ends up
> being about solving the problem; there are always moments of tension and
> what may appear as endless discussion (look at the thread on
> qdisc_is_running), but in the end it doesnt turn out into a high school
> debate to prove one is better than the other. So maybe it is the mutual
> respect and maturity in the discussion.
Actually that thread was cleared up by Herbert nice and fast :) I too
enjoy working with him, but I think Herbert is a special case as his
arguments are in my opinion always perfectly clear, usually correct,
understandable and nicely formulated. He doesn't leave you much
choice :)
Probably also a bit of a language issue, I'm not able to express myself
as well as he is (especially not as friendly).
> In regards to "areas", you may be right; i cross more into Herberts path
> than he does mine.
> My reaction in this may be related to the way i treat other people and
> my expectations:
> When i submit patches to i would make sure i cc people who i think have
> stakes or better insight in that area even if they seem irrelevant.
> In-fact i may have even private conversations with them first if they
> are large patches.
> As an example i would make sure i cc you if i had some netfilter issues
> or Herbert when i submit ipsec patches and we would have a gazillion
> discussions which would sometimes result in the patches being totally
> re-written. It doesnt make me happy all the time (especially when i have
> to drop patches), but in the end it made me work better with that person
> and removes doubt in my mind that i have missed something. Unfortunately
> this approach (even in non-linux areas) is a lot of times
> taken for a weakness.
I always had the feeling you're beeing "protective", in the form of
pulling people in discussions not really related to the subject.
That was about it with my opinion on the matter, I think we will be
able to resolve this in a better way personally.
^ 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