* [PATCH 1/5] tg3: Add tg3_netif_stop() in vlan functions
From: Michael Chan @ 2006-06-30 1:29 UTC (permalink / raw)
To: davem; +Cc: netdev
Add tg3_netif_stop() when changing the vlgrp (vlan group) pointer. It
is necessary to quiesce the device before changing that pointer.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 35f9316..2447fa3 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -8738,6 +8738,9 @@ static void tg3_vlan_rx_register(struct
{
struct tg3 *tp = netdev_priv(dev);
+ if (netif_running(dev))
+ tg3_netif_stop(tp);
+
tg3_full_lock(tp, 0);
tp->vlgrp = grp;
@@ -8746,16 +8749,25 @@ static void tg3_vlan_rx_register(struct
__tg3_set_rx_mode(dev);
tg3_full_unlock(tp);
+
+ if (netif_running(dev))
+ tg3_netif_start(tp);
}
static void tg3_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid)
{
struct tg3 *tp = netdev_priv(dev);
+ if (netif_running(dev))
+ tg3_netif_stop(tp);
+
tg3_full_lock(tp, 0);
if (tp->vlgrp)
tp->vlgrp->vlan_devices[vid] = NULL;
tg3_full_unlock(tp);
+
+ if (netif_running(dev))
+ tg3_netif_start(tp);
}
#endif
^ permalink raw reply related
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 1:18 UTC (permalink / raw)
To: Thomas Graf; +Cc: kaber, netdev, David Miller
In-Reply-To: <20060630005535.GD14627@postel.suug.ch>
On Fri, 2006-30-06 at 02:55 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-29 20:48
> The point is to avoid having an atomic operation for every packet
> when setting iif in netif_receive_skb(). If it was only for
> mirred nobody would complain I guess.
>
I never intended to punish all users. I think i was misunderstood.
The only problem is where do you decrement the refcount when you
increment at mirred?
In your case, I assume it is at some sort of rule destruction?
> > I think whether it becomes ifindex or pointer you need to increment the
> > refcounter. and decrement somewhere.
> > The challenge for me is a choice to use more cycles if you use ifindex
> > vs less cycles with a pointer. The advantage for going with ifindex
> > would be to save those bits(if you rearrange). The question is which is
> > reasonable?;->
>
> The third choice is to just don't care if the interface goes away
> but have a chance to figure it out and just assume as if it would
> have never been set. The number of devices that can disappear w/o
> user control is very very limited and not worth an atomic operation
> for every single packet.
>
Now that you mention this - I think that option 3 is what we said last
time we had this discussion ;->
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 1:11 UTC (permalink / raw)
To: Thomas Graf; +Cc: Patrick McHardy, David Miller, netdev
In-Reply-To: <20060630004640.GC14627@postel.suug.ch>
On Fri, 2006-30-06 at 02:46 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-29 20:03
> > On Fri, 2006-30-06 at 01:39 +0200, Thomas Graf wrote:
> > > * jamal <hadi@cyberus.ca> 2006-06-29 19:23
> >
> > > > not at all. Let me explain the design intent further below.
> > >
> > > Then let me show you what your code does:
> > >
> > > [mirred attached to filter on eth0 redirecting to ifb0]
> > >
> > > tcf_mirred(): skb2->input_dev = skb->dev; (skb2->input_dev=eth0)
> > > ifb_xmit(): skb->dev = skb->input_dev; (skb->dev=eth0)
> > > skb->input_dev = dev; (skb->input_dev=ifb0)
> > >
> > > So when reentering the stack the skb looks like it would be
> > > on eth0 coming from ifb0. Is that what you wanted?
> >
> > ok, that looks like egress side of the stack, correct?
>
> No, that's the ingress side leaving ifb again via netif_rx()
>
> skb->dev should represent the from/at= and not to=.
>
Heres what it would look at ingress:
step 0: coming from wire via eth0,
dev=eth0, input_dev=eth0
step 1: redirect to ifb0, leaving redirect
dev=ifb0, input_dev=eth0
step 2: leaving ifb0, coming back to ingress side of stack
dev= eth0, input_dev=ifb0
Again, it gets interesting when you have redirection multiple times
and create loops. It will get more interesting when i submit the code
for redirecting to ingress.
The good news is there is very strong consistency.
I dont know if "at" is the correct description. I visualize it as
hitting the stack just "at" the point.
when the packet first comes in both from/to point to eth0.
So the semantics are the same as in egress.
> For egress your code is correct although impossible to guess
> right due to total lack of a comment where it would make sense
> and naming that doesn't give any implications.
>
There are some simple comments and I have been trying very hard to
explain this for a long time.
Patrick was the last person who tortured me ;-> Perhaps i need to
write a document.
> When leaving ifb0 you want for...
> ... egress:
> skb->dev=to (eth0) skb->iif=from (ifb0)
> ... ingress:
> skb->dev=at (ifb0) skb->iif=from (eth0)
>
Yes, this is correct. I described the flow of the first one in the
earlier email and the ingress side.
Although lets not talk about iif yet. I posed a question earlier on
which scheme would be better.
> So we move the update to the tasklet and set skb->dev to
> skb->iif before dev_queue_xmit() and skb->dev = dev (ifb)
> before calling netif_rx()
>
> Does that fullfil your requirements?
You lost me on what you are trying to achieve. Just restore the line you
removed in ifb and things would be fine. Lets then settle the issue of
iif vs input_dev.
cheers,
jamal
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Shailabh Nagar @ 2006-06-30 1:11 UTC (permalink / raw)
To: Andrew Morton
Cc: hadi, pj, Valdis.Kletnieks, jlan, balbir, csturtiv, linux-kernel,
netdev
In-Reply-To: <20060629180502.3987a98e.akpm@osdl.org>
Andrew Morton wrote:
>Shailabh Nagar <nagar@watson.ibm.com> wrote:
>
>
>>The rates (or upper bounds) that are being discussed here, as of now,
>>are 1000 exits/sec/CPU for
>>1024 CPU systems. That would be roughly 1M exits/system *
>>248Bytes/message = 248 MB/sec.
>>
>>
>
>I think it's worth differentiating between burst rates and sustained rates
>here.
>
>One could easily imagine 10,000 threads all exiting at once, and the user
>being interested in reliably collecting the results.
>
>But if the machine is _sustaining_ such a high rate then that means that
>these exiting tasks all have a teeny runtime and the user isn't going to be
>interested in the per-thread statistics.
>
>So if we can detect the silly sustained-high-exit-rate scenario then it
>seems to me quite legitimate to do some aggressive data reduction on that.
>Like, a single message which says "20,000 sub-millisecond-runtime tasks
>exited in the past second" or something.
>
>
The "buffering within taskstats" might be a way out then.
As long as the user is willing to pay the price in terms of memory, we
can collect the exiting task's
taskstats data but not send it immediately (taskstats_cache would grow)
unless a high water mark had
been crossed. Otherwise a timer event would do the sends of accumalated
taskstats (not all at once but
iteratively if necessary).
At task exit, despite doing a few rounds of sending of pending data, if
netlink were still reporting errors
then it would be a sign of unsustainable rate and the pending queue
could be dropped and a message
like you suggest could be sent.
Thoughts ?
--Shailabh
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Andrew Morton @ 2006-06-30 1:05 UTC (permalink / raw)
To: Shailabh Nagar
Cc: hadi, pj, Valdis.Kletnieks, jlan, balbir, csturtiv, linux-kernel,
netdev
In-Reply-To: <44A47285.6060307@watson.ibm.com>
Shailabh Nagar <nagar@watson.ibm.com> wrote:
>
> The rates (or upper bounds) that are being discussed here, as of now,
> are 1000 exits/sec/CPU for
> 1024 CPU systems. That would be roughly 1M exits/system *
> 248Bytes/message = 248 MB/sec.
I think it's worth differentiating between burst rates and sustained rates
here.
One could easily imagine 10,000 threads all exiting at once, and the user
being interested in reliably collecting the results.
But if the machine is _sustaining_ such a high rate then that means that
these exiting tasks all have a teeny runtime and the user isn't going to be
interested in the per-thread statistics.
So if we can detect the silly sustained-high-exit-rate scenario then it
seems to me quite legitimate to do some aggressive data reduction on that.
Like, a single message which says "20,000 sub-millisecond-runtime tasks
exited in the past second" or something.
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Thomas Graf @ 2006-06-30 0:55 UTC (permalink / raw)
To: jamal; +Cc: David Miller, netdev, kaber
In-Reply-To: <1151628520.8922.99.camel@jzny2>
* jamal <hadi@cyberus.ca> 2006-06-29 20:48
> the ifb references it; only mirred redirects to the ifb at the moment.
> You would need to increment in mirred, no?
> Why do i feel i am missing something? ;->
The point is to avoid having an atomic operation for every packet
when setting iif in netif_receive_skb(). If it was only for
mirred nobody would complain I guess.
> I think whether it becomes ifindex or pointer you need to increment the
> refcounter. and decrement somewhere.
> The challenge for me is a choice to use more cycles if you use ifindex
> vs less cycles with a pointer. The advantage for going with ifindex
> would be to save those bits(if you rearrange). The question is which is
> reasonable?;->
The third choice is to just don't care if the interface goes away
but have a chance to figure it out and just assume as if it would
have never been set. The number of devices that can disappear w/o
user control is very very limited and not worth an atomic operation
for every single packet.
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 0:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kaber, tgraf
In-Reply-To: <20060629.172948.59656719.davem@davemloft.net>
On Thu, 2006-29-06 at 17:29 -0700, David Miller wrote:
> From: jamal <hadi@cyberus.ca>
> Date: Thu, 29 Jun 2006 20:26:20 -0400
[..]
> > I see; i take it if things were moved around that may change?
>
> Yes.
>
Ok, relief - so i was not totally unreasonable then ;->
> > Can you avoid doing the refcount?
> > Note Thomas is doing dev_get_by_index (which will do the atomic ref
> > count).
>
> He is doing that where skb->input_device is needed, which is
> what we want.
>
I am saying the same thing as well - i think. mirred touches
the input_dev and therefore setting the refcount in mirred is valid -
but iam unsure where to unset it.
> > I didnt quiet follow, the ref count seems only needed in the
> > redirection, no?
>
> I'm saying that, we don't need the refcount, just setting
> the skb->input_index thing, unless someone actually cares
> about the input device.
>
the ifb references it; only mirred redirects to the ifb at the moment.
You would need to increment in mirred, no?
Why do i feel i am missing something? ;->
> As long as the packet hits not paths that care about the
> SKB input device, no atomic refcounts are taken. It's
> just an integer sitting there in the SKB.
indeed.
I think whether it becomes ifindex or pointer you need to increment the
refcounter. and decrement somewhere.
The challenge for me is a choice to use more cycles if you use ifindex
vs less cycles with a pointer. The advantage for going with ifindex
would be to save those bits(if you rearrange). The question is which is
reasonable?;->
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 39 of 39] IB/ipath - use streaming copy in RDMA interrupt handler to reduce packet loss
From: David Miller @ 2006-06-30 0:47 UTC (permalink / raw)
To: rick.jones2; +Cc: bos, akpm, rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <44A473D5.70809@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Thu, 29 Jun 2006 17:44:05 -0700
> Then is prefetching in memcpy really that important to them.
Not really, the thread just blocks while waiting for memory.
On stores they do a cacheline fill optimization similar to
the powerpc.
> Relying on PCI-X devices to issue multiple requests then?
Perhaps :)
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Thomas Graf @ 2006-06-30 0:46 UTC (permalink / raw)
To: jamal; +Cc: netdev, David Miller, Patrick McHardy
In-Reply-To: <1151625826.8922.58.camel@jzny2>
* jamal <hadi@cyberus.ca> 2006-06-29 20:03
> On Fri, 2006-30-06 at 01:39 +0200, Thomas Graf wrote:
> > * jamal <hadi@cyberus.ca> 2006-06-29 19:23
>
> > > not at all. Let me explain the design intent further below.
> >
> > Then let me show you what your code does:
> >
> > [mirred attached to filter on eth0 redirecting to ifb0]
> >
> > tcf_mirred(): skb2->input_dev = skb->dev; (skb2->input_dev=eth0)
> > ifb_xmit(): skb->dev = skb->input_dev; (skb->dev=eth0)
> > skb->input_dev = dev; (skb->input_dev=ifb0)
> >
> > So when reentering the stack the skb looks like it would be
> > on eth0 coming from ifb0. Is that what you wanted?
>
> ok, that looks like egress side of the stack, correct?
No, that's the ingress side leaving ifb again via netif_rx()
skb->dev should represent the from/at= and not to=.
For egress your code is correct although impossible to guess
right due to total lack of a comment where it would make sense
and naming that doesn't give any implications.
When leaving ifb0 you want for...
... egress:
skb->dev=to (eth0) skb->iif=from (ifb0)
... ingress:
skb->dev=at (ifb0) skb->iif=from (eth0)
So we move the update to the tasklet and set skb->dev to
skb->iif before dev_queue_xmit() and skb->dev = dev (ifb)
before calling netif_rx()
Does that fullfil your requirements?
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Ben Greear @ 2006-06-30 0:44 UTC (permalink / raw)
To: David Miller; +Cc: hadi, tgraf, kaber, netdev
In-Reply-To: <20060629.172948.59656719.davem@davemloft.net>
David Miller wrote:
> I'm saying that, we don't need the refcount, just setting
> the skb->input_index thing, unless someone actually cares
> about the input device.
>
> As long as the packet hits not paths that care about the
> SKB input device, no atomic refcounts are taken. It's
> just an integer sitting there in the SKB.
Also, if this lookup is to be done multiple times per skb, we could
do the lookup once and grab the ref at that time and store the
pointer in the skb. If you wanted to be truly horible about it..could
use a 64-bit input_index and copy the pointer there (and set a flag somewhere
noting it is no longer an index but a pointer) so save the extra
64-bits.
Ben
> -
> 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
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 39 of 39] IB/ipath - use streaming copy in RDMA interrupt handler to reduce packet loss
From: Rick Jones @ 2006-06-30 0:44 UTC (permalink / raw)
To: David Miller
Cc: bos, akpm, rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <20060629.173206.48800902.davem@davemloft.net>
David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Thu, 29 Jun 2006 17:28:50 -0700
>
>
>>I thought that most PCI controllers (that is to say the things bridging
>>PCI to the rest of the system) could do prefetching and/or that PCI-X
>>(if not PCI, no idea about PCI-e) cards could issue multiple
>>transactions anyway?
>
>
> People doing deep CMT chips have found out that all of that
> prefetching and store buffering is unnecessary when everything is so
> tightly integrated.
Then is prefetching in memcpy really that important to them (BTW besides
Sun/Niagra who are doing "deep CMT"?)
> All of the previous UltraSPARC boxes before Niagara had a
> streaming cache sitting on the PCI controller. It basically
> prefetched for reads and collected writes from PCI devices
> into cacheline sized chunks.
>
> The PCI controller in the current Niagara systems has none of that
> stuff.
Relying on PCI-X devices to issue multiple requests then?
rick jones
^ permalink raw reply
* Re: [PATCH 2.6.17] support for TSO over IPv6
From: Herbert Xu @ 2006-06-30 0:39 UTC (permalink / raw)
To: Ananda Raju
Cc: netdev, jgarzik, shemminger, Leonid.Grossman, Ravinandan.Arakali,
sivakumar.subramani, Sriram.Rapuru, Michael Chan
In-Reply-To: <E1Fw604-0006yP-00@gondolin.me.apana.org.au>
On Fri, Jun 30, 2006 at 09:32:44AM +1000, Herbert Xu wrote:
>
> > diff -upNr netdev.org/include/linux/skbuff.h netdev.ipv6_tso/include/linux/skbuff.h
> > --- netdev.org/include/linux/skbuff.h 2006-06-27 07:30:36.000000000 -0700
> > +++ netdev.ipv6_tso/include/linux/skbuff.h 2006-06-27 07:38:48.000000000 -0700
> > @@ -170,8 +170,9 @@ enum {
> > };
> >
> > enum {
> > - SKB_GSO_TCPV4 = 1 << 0,
> > - SKB_GSO_UDPV4 = 1 << 1,
> > + SKB_GSO_TCP = 1 << 0,
> > + SKB_GSO_UDP = 1 << 1,
> > + SKB_GSO_TCPV6 = 1 << 2,
> > };
>
> BTW, you should rediff against Dave's current tree which has a few
> extra bits there.
>
> You should also leave TCPV4 as is and just add the TCPV6 bit.
BTW, does your card handle ECN correctly? If not then we should change
the new ECN bit to apply to both TCPv4 and TCPv6 since
1) We now have a piece of hardware that handles TSO6 and it doesn't do ECN.
2) It's quite likely that if the NIC can handle ECN in TCPv4 then it can do
it in TCPv6.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Shailabh Nagar @ 2006-06-30 0:38 UTC (permalink / raw)
To: hadi
Cc: Andrew Morton, pj, Valdis.Kletnieks, jlan, balbir, csturtiv,
linux-kernel, netdev
In-Reply-To: <1151621692.8922.4.camel@jzny2>
jamal wrote:
>On Thu, 2006-29-06 at 16:01 -0400, Shailabh Nagar wrote:
>
>
>
>>Jamal,
>>any thoughts on the flow control capabilities of netlink that apply here
>>? Usage of the connection is to supply statistics data to userspace.
>>
>>
>>
>
>if you want reliable delivery, then you cant just depend on async events
>from the kernel -> user - which i am assuming is the way stats get
>delivered as processes exit?
>
Yes.
>Sorry, i dont remember the details. You
>need some synchronous scheme to ask the kernel to do a "get" or "dump".
>
>
Oh, yes. Dump is synchronous. So it won't be useful unless we buffer
task exit records within
taskstats.
>Lets be clear about one thing:
>The problem really has nothing to do with gen/netlink or any other
>scheme you use;->
>It has everything to do with reliability implications and the fact
>that you need to assume memory is a finite resource - at one point
>or another you will run out of memory ;-> And of course then messages
>will be lost. So for gen/netlink, just make sure you have large socket
>buffer and you would most likely be fine.
>I havent seen how the numbers were reached: But if you say you receive
>14K exits/sec each of which is a 50B message, I would think a 1M socket
>buffer would be plenty.
>
>
The rates (or upper bounds) that are being discussed here, as of now,
are 1000 exits/sec/CPU for
1024 CPU systems. That would be roughly 1M exits/system *
248Bytes/message = 248 MB/sec.
>You can find out about lack of memory in netlink when you get a ENOBUFS.
>As an example, you should then do a kernel query. Clearly if you do a
>query of that sort, you may not want to find obsolete info. Therefore,
>as a suggestion, you may want to keep sequence numbers of sorts as
>markers. Perhaps keep a 32-bit field which monotically increases per
>process exit or use the pid as the sequence number etc..
>
>As for throttling - Shailabh, I think we talked about this:
>- You could maintain info using some thresholds and timer. Then
>when a timer expires or threshold is exceeded send to user space.
>
>
Hmm. So we could buffer the per-task exit data within taskstats (the mem
consumption would grow
but thats probably not a problem) and then send it out later.
Jay - would not getting exit data soon after exit be a problem for CSA ?
I'm guessing not, if the
timeout is kept small enough. Internally, taskstats could always pace
its sends so that "too much"
isn't sent out at one shot.
--Shailabh
^ permalink raw reply
* Re: [PATCH 39 of 39] IB/ipath - use streaming copy in RDMA interrupt handler to reduce packet loss
From: David Miller @ 2006-06-30 0:32 UTC (permalink / raw)
To: rick.jones2; +Cc: bos, akpm, rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <44A47042.8060203@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Thu, 29 Jun 2006 17:28:50 -0700
> I thought that most PCI controllers (that is to say the things bridging
> PCI to the rest of the system) could do prefetching and/or that PCI-X
> (if not PCI, no idea about PCI-e) cards could issue multiple
> transactions anyway?
People doing deep CMT chips have found out that all of that
prefetching and store buffering is unnecessary when everything is so
tightly integrated.
All of the previous UltraSPARC boxes before Niagara had a
streaming cache sitting on the PCI controller. It basically
prefetched for reads and collected writes from PCI devices
into cacheline sized chunks.
The PCI controller in the current Niagara systems has none of that
stuff.
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: David Miller @ 2006-06-30 0:29 UTC (permalink / raw)
To: hadi; +Cc: tgraf, kaber, netdev
In-Reply-To: <1151627180.8922.81.camel@jzny2>
From: jamal <hadi@cyberus.ca>
Date: Thu, 29 Jun 2006 20:26:20 -0400
> On Thu, 2006-29-06 at 17:12 -0700, David Miller wrote:
> > The objects around it are pointers, which are 64-bit, and thus
> > the 32-bit object gets padded out to 64-bits in the layout of
> > the struct so that the next pointer member can be properly
> > aligned.
> >
> > It does not change the size of sk_buff at all.
> >
>
> I see; i take it if things were moved around that may change?
Yes.
> > > Yes, it is a bug, but:
> > > dev_hold/put dont work anymore? why do you need an ifindex instead?
> >
> > You sure you want to do that atomic operation on every single
> > input packet, regardless of whether egress operations are
> > using it or not?
> >
>
> Can you avoid doing the refcount?
> Note Thomas is doing dev_get_by_index (which will do the atomic ref
> count).
He is doing that where skb->input_device is needed, which is
what we want.
> I didnt quiet follow, the ref count seems only needed in the
> redirection, no?
I'm saying that, we don't need the refcount, just setting
the skb->input_index thing, unless someone actually cares
about the input device.
As long as the packet hits not paths that care about the
SKB input device, no atomic refcounts are taken. It's
just an integer sitting there in the SKB.
^ permalink raw reply
* Re: [PATCH 38 of 39] IB/ipath - More changes to support InfiniPath on PowerPC 970 systems
From: Dave Olson @ 2006-06-30 0:28 UTC (permalink / raw)
To: David Miller
Cc: bos, akpm, rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <fa./e2EfI5SsRLt5d/gFrBSOnDZpZ0@ifi.uio.no>
On Thu, 29 Jun 2006, David Miller wrote:
| From: Bryan O'Sullivan <bos@pathscale.com>
| Date: Thu, 29 Jun 2006 14:41:29 -0700
|
| > ipath_core-$(CONFIG_X86_64) += ipath_wc_x86_64.o
| > +ipath_core-$(CONFIG_PPC64) += ipath_wc_ppc64.o
|
| Again, don't put these kinds of cpu specific functions
| into the infiniband driver. They are potentially globally
| useful, not something only Infiniband might want to do.
The new code simply sets a flag as to whether instruction level
write barriers need to be used or not, it doesn't contain actual
code.
The older file (already accepted) does have some setup code, as well as
code setting flags, due to the fact that Bryan mentioned in his reply,
that this stuff simply doesn't yet exist in a generic form. It's not
clear to me that it can ever be made to exist in a generic form that will
actually work on multiple architectures (or that there are enough users
to be worth trying). We can make the attempt, but so far it's pretty
non-generic, in it's very nature.
Dave Olson
olson@unixfolk.com
http://www.unixfolk.com/dave
^ permalink raw reply
* Re: [PATCH 39 of 39] IB/ipath - use streaming copy in RDMA interrupt handler to reduce packet loss
From: Rick Jones @ 2006-06-30 0:28 UTC (permalink / raw)
To: David Miller
Cc: bos, akpm, rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <20060629.164623.59469884.davem@davemloft.net>
> If you bypass the L2 cache, it's pointless because the next
> agent (PCI controller, CPU thread, etc.) is going to need the
> data in the L2 cache.
>
> It's better in that kind of setup to eat the L2 cache miss overhead in
> memcpy since memcpy can usually prefetch and store buffer in order to
> absorb some of the L2 miss costs.
I thought that most PCI controllers (that is to say the things bridging
PCI to the rest of the system) could do prefetching and/or that PCI-X
(if not PCI, no idea about PCI-e) cards could issue multiple
transactions anyway?
rick jones
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 0:26 UTC (permalink / raw)
To: David Miller; +Cc: tgraf, kaber, netdev
In-Reply-To: <20060629.171215.112621072.davem@davemloft.net>
On Thu, 2006-29-06 at 17:12 -0700, David Miller wrote:
> From: jamal <hadi@cyberus.ca>
> Date: Thu, 29 Jun 2006 20:08:19 -0400
>
> > What am i missing?
> > on 64bit machine, does it not save 32 bits to use an ifindex as opposed
> > to the pointer?
>
> The objects around it are pointers, which are 64-bit, and thus
> the 32-bit object gets padded out to 64-bits in the layout of
> the struct so that the next pointer member can be properly
> aligned.
>
> It does not change the size of sk_buff at all.
>
I see; i take it if things were moved around that may change?
> > Yes, it is a bug, but:
> > dev_hold/put dont work anymore? why do you need an ifindex instead?
>
> You sure you want to do that atomic operation on every single
> input packet, regardless of whether egress operations are
> using it or not?
>
Can you avoid doing the refcount?
Note Thomas is doing dev_get_by_index (which will do the atomic ref
count).
For me the choice is between having the iif and:
- __get device from ifindex
- reference dev->something
vs getting the input_dev and
- reference dev->something
> We should put the cost of features at the actual users, and not
> impose it upon everyone.
I didnt quiet follow, the ref count seems only needed in the
redirection, no?
cheers,
jamal
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: jamal @ 2006-06-30 0:15 UTC (permalink / raw)
To: Sam Vilain
Cc: Herbert Poetzl, Alexey Kuznetsov, viro, devel, dev, Andrew Morton,
clg, serue, netdev, linux-kernel, Andrey Savochkin,
Daniel Lezcano, Ben Greear, Dave Hansen, Alexey Kuznetsov,
Eric W. Biederman
In-Reply-To: <44A44124.5010602@vilain.net>
On Fri, 2006-30-06 at 09:07 +1200, Sam Vilain wrote:
> jamal wrote:
> > Makes sense for the host side to have naming convention tied
> > to the guest. Example as a prefix: guest0-eth0. Would it not
> > be interesting to have the host also manage these interfaces
> > via standard tools like ip or ifconfig etc? i.e if i admin up
> > guest0-eth0, then the user in guest0 will see its eth0 going
> > up.
>
> That particular convention only works if you have network namespaces and
> UTS namespaces tightly bound.
that would be one approach. Another less sophisticated approach is to
have no binding whatsoever, rather some translation table to map two
unrelated devices.
> We plan to have them separate - so for
> that to work, each network namespace could have an arbitrary "prefix"
> that determines what the interface name will look like from the outside
> when combined. We'd have to be careful about length limits.
>
> And guest0-eth0 doesn't necessarily make sense; it's not really an
> ethernet interface, more like a tun or something.
>
it wouldnt quiet fit as a tun device. More like a mirror side of the
guest eth0 created on the host side
i.e a sort of passthrough device with one side visible on the host (send
from guest0-eth0 is received on eth0 in the guest and vice-versa).
Note this is radically different from what i have heard Andrey and co
talk about and i dont wanna disturb any shit because there seems to be
some agreement. But if you address me i respond because it is very
interesting a topic;->
> So, an equally good convention might be to use sequential prefixes on
> the host, like "tun", "dummy", or a new prefix - then a property of that
> is what the name of the interface is perceived to be to those who are in
> the corresponding network namespace.
>
> Then the pragmatic question becomes how to correlate what you see from
> `ip addr list' to guests.
on the host ip addr and the one seen on the guest side are the same.
Except one is seen (on the host) on guest0-eth0 and another is seen
on eth0 (on guest).
Anyways, ignore what i am saying if it is disrupting the discussion.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 2.6.17] support for TSO over IPv6
From: David Miller @ 2006-06-30 0:12 UTC (permalink / raw)
To: herbert
Cc: Ananda.Raju, netdev, jgarzik, shemminger, Leonid.Grossman,
Ravinandan.Arakali, sivakumar.subramani, Sriram.Rapuru
In-Reply-To: <E1Fw604-0006yP-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 30 Jun 2006 09:32:44 +1000
> BTW, you should rediff against Dave's current tree which has a few
> extra bits there.
I just rebased that, so feel free to use it as the base for
the patch now.
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: David Miller @ 2006-06-30 0:12 UTC (permalink / raw)
To: hadi; +Cc: netdev, kaber, tgraf
In-Reply-To: <1151626099.8922.64.camel@jzny2>
From: jamal <hadi@cyberus.ca>
Date: Thu, 29 Jun 2006 20:08:19 -0400
> What am i missing?
> on 64bit machine, does it not save 32 bits to use an ifindex as opposed
> to the pointer?
The objects around it are pointers, which are 64-bit, and thus
the 32-bit object gets padded out to 64-bits in the layout of
the struct so that the next pointer member can be properly
aligned.
It does not change the size of sk_buff at all.
> Yes, it is a bug, but:
> dev_hold/put dont work anymore? why do you need an ifindex instead?
You sure you want to do that atomic operation on every single
input packet, regardless of whether egresss operations are
using it or not?
We should put the cost of features at the actual users, and not
impose it upon everyone.
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 0:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kaber, tgraf
In-Reply-To: <20060629.164732.41636454.davem@davemloft.net>
On Thu, 2006-29-06 at 16:47 -0700, David Miller wrote:
> From: Thomas Graf <tgraf@suug.ch>
> Date: Fri, 30 Jun 2006 01:39:33 +0200
>
> > * jamal <hadi@cyberus.ca> 2006-06-29 19:23
> > > I know your intent is noble in trying to save the 32 bits on 64 bit
> > > machines (at least thats where your patch seems to have started) but the
> > > cost:benefit ratio as i have pointed out is unreasonable.
> >
> > Did I ever claim this? You made this up right now. As of now
> > it doesn't save a single bit.
>
> Right.
>
What am i missing?
on 64bit machine, does it not save 32 bits to use an ifindex as opposed
to the pointer?
> From what I can see Thomas's work allows to do correct
> reference counting on the input_dev, something which is
> not possible right now and is a bug.
Yes, it is a bug, but:
dev_hold/put dont work anymore? why do you need an ifindex instead?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 28 of 39] IB/ipath - Fixes a bug where our delay for EEPROM no longer works due to compiler reordering
From: Andrew Morton @ 2006-06-30 0:07 UTC (permalink / raw)
To: Bryan O'Sullivan; +Cc: rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <5f3c0b2d446d78e3327f.1151617279@eng-12.pathscale.com>
"Bryan O'Sullivan" <bos@pathscale.com> wrote:
>
> The mb() prevents the compiler from reordering on this function, with some versions
> of gcc and -Os optimization. The result is random failures in the EEPROM read
> without this change.
>
>
> Signed-off-by: Dave Olson <dave.olson@qlogic.com>
> Signed-off-by: Bryan O'Sullivan <bryan.osullivan@qlogic.com>
>
> diff -r 7d22a8963bda -r 5f3c0b2d446d drivers/infiniband/hw/ipath/ipath_eeprom.c
> --- a/drivers/infiniband/hw/ipath/ipath_eeprom.c Thu Jun 29 14:33:26 2006 -0700
> +++ b/drivers/infiniband/hw/ipath/ipath_eeprom.c Thu Jun 29 14:33:26 2006 -0700
> @@ -186,6 +186,7 @@ bail:
> */
> static void i2c_wait_for_writes(struct ipath_devdata *dd)
> {
> + mb();
> (void)ipath_read_kreg32(dd, dd->ipath_kregs->kr_scratch);
> }
>
That's a bit weird. I wouldn't have expected the compiler to muck around
with a readl().
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 0:03 UTC (permalink / raw)
To: Thomas Graf; +Cc: netdev, David Miller, Patrick McHardy
In-Reply-To: <20060629233933.GB14627@postel.suug.ch>
On Fri, 2006-30-06 at 01:39 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-29 19:23
> > not at all. Let me explain the design intent further below.
>
> Then let me show you what your code does:
>
> [mirred attached to filter on eth0 redirecting to ifb0]
>
> tcf_mirred(): skb2->input_dev = skb->dev; (skb2->input_dev=eth0)
> ifb_xmit(): skb->dev = skb->input_dev; (skb->dev=eth0)
> skb->input_dev = dev; (skb->input_dev=ifb0)
>
> So when reentering the stack the skb looks like it would be
> on eth0 coming from ifb0. Is that what you wanted?
ok, that looks like egress side of the stack, correct?
indeed thats what i meant earlier i.e above looks right. Another way to
look at it, is that on the stack, the "dev" part acts as a "to" label of
the direction and the "input_dev" maps to the "from".
step 0: Packet arriving at egress of eth0
It will have skb->dev pointing to "eth0" and skb->input_dev will depend
on whether it is coming from the local path (in which it will be NULL)
or it was being routed (in which case it will reflect the netdevice it
last passed on input.
Step 1: when it leaves redirect
As you note it will have indev("from") = eth0 and dev("to") still "ifb0"
Step 2: when it leaves ifb going back to eth0
it will have input_dev("from") = ifb0 and dev("to") "eth0"
Of course this gets more interesting if you had say redirected to
another device like lo which redirected to ifb1. Or when you try to
create loops etc.
And if you look at ingress, it will be slightly different; however,
in both cases (ingress/egress) things are consistent in the labeling of
from/to to be input_dev/dev
> Shouldn't
> it be skb->dev=ifb0 skb->input_dev=eth0? That's what my patch
> would change it to.
>
yes, that would change the semantics
> > I know your intent is noble in trying to save the 32 bits on 64 bit
> > machines (at least thats where your patch seems to have started) but the
> > cost:benefit ratio as i have pointed out is unreasonable.
>
> Did I ever claim this? You made this up right now. As of now
> it doesn't save a single bit.
Ok, I apologize - i assumed it has something to do with skb diet.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 2/2] [IrDA] Fix the AU1000 FIR dependencies
From: David Miller @ 2006-06-30 0:03 UTC (permalink / raw)
To: samuel-jcdQHdrhKHMdnm+yROfE0A
Cc: akpm-3NddpPZAyC0, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ralf-6z/3iImG2C8G8FEW9MqTrA,
bunk-HeJ8Db2Gnd6zQB+pC5nmwQ,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
reiga-dF3JGIbHi9Ffir3NkZym1w
In-Reply-To: <20060630065607.GB4729-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
From: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Date: Fri, 30 Jun 2006 09:56:07 +0300
> AU1000 FIR is broken, it should depend on SOC_AU1000.
>
> Spotted by Jean-Luc Leger.
>
> Signed-off-by: Adrian Bunk <bunk-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Applied, thanks.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ 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