* [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: jamal @ 2007-10-09 2:14 UTC (permalink / raw)
To: David Miller
Cc: johnpol, herbert, jeff, Robert.Olsson, netdev, rdreier,
peter.p.waskiewicz.jr, mcarlson, gaagaan, jagana, general, mchan,
tgraf, randy.dunlap, sri, shemminger, kaber
In-Reply-To: <20071008.184126.124062865.davem@davemloft.net>
On Mon, 2007-08-10 at 18:41 -0700, David Miller wrote:
> I also want to point out another issue. Any argument wrt. reordering
> is specious at best because right now reordering from qdisc to device
> happens anyways.
>
> And that's because we drop the qdisc lock first, then we grab the
> transmit lock on the device and submit the packet. So, after we
> drop the qdisc lock, another cpu can get the qdisc lock, get the
> next packet (perhaps a lower priority one) and then sneak in to
> get the device transmit lock before the first thread can, and
> thus the packets will be submitted out of order.
>
You forgot QDISC_RUNNING Dave;-> the above cant happen.
Essentially at any one point in time, we are guaranteed that we can have
multiple cpus enqueueing but only can be dequeueing (the one that
managed to grab QDISC_RUNNING) i.e multiple producers to the qdisc queue
but only one consumer. Only the dequeuer has access to the txlock.
> This, along with other things, makes me believe that ordering really
> doesn't matter in practice. And therefore, in practice, we can treat
> everything from the qdisc to the real hardware as a FIFO even if
> something else is going on inside the black box which might reorder
> packets on the wire.
I think it is important to get the scheduling right - estimations can be
a last resort. For example, If i have voip competing for the wire with
ftp on two different rings/cpus and i specified that voip should be more
important i may consider equipment faulty if it works "most of the
time" (when ftp is not clogging the wire) and at times i am asked to
repeat what i just said.
cheers,
jamal
^ permalink raw reply
* [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Jeff Garzik @ 2007-10-09 2:12 UTC (permalink / raw)
To: David Miller
Cc: johnpol, herbert, gaagaan, Robert.Olsson, netdev, rdreier,
peter.p.waskiewicz.jr, hadi, mcarlson, jagana, general, mchan,
tgraf, randy.dunlap, sri, shemminger, kaber
In-Reply-To: <20071008.184126.124062865.davem@davemloft.net>
David Miller wrote:
> 1) A library for transmit load balancing functions, with an interface
> that can be made visible to userspace. I can write this and test
> it on real multiqueue hardware.
>
> The whole purpose of this library is to set skb->queue_mapping
> based upon the load balancing function.
>
> Facilities will be added to handle virtualization port selection
> based upon destination MAC address as one of the "load balancing"
> methods.
Groovy.
I'm interested in working on a load balancer function that approximates
skb->queue_mapping = smp_processor_id()
I'd be happy to code and test in that direction, based on your lib.
> 2) Switch the default qdisc away from pfifo_fast to a new DRR fifo
> with load balancing using the code in #1. I think this is kind
> of in the territory of what Peter said he is working on.
>
> I know this is controversial, but realistically I doubt users
> benefit at all from the prioritization that pfifo provides. They
> will, on the other hand, benefit from TX queue load balancing on
> fast interfaces.
IMO the net driver really should provide a hint as to what it wants.
8139cp and tg3 would probably prefer multiple TX queue behavior to match
silicon behavior -- strict prio.
And I'll volunteer to write the net driver code for that, if people want
to see how things would look for that type of hardware packet scheduling.
> 3) Work on discovering a way to make the locking on transmit as
> localized to the current thread of execution as possible. Things
> like RCU and statistic replication, techniques we use widely
> elsewhere in the stack, begin to come to mind.
Definitely.
Jeff
^ permalink raw reply
* [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Herbert Xu @ 2007-10-09 2:04 UTC (permalink / raw)
To: David Miller
Cc: johnpol, jeff, Robert.Olsson, netdev, rdreier,
peter.p.waskiewicz.jr, hadi, mcarlson, gaagaan, jagana, general,
mchan, tgraf, randy.dunlap, shemminger, kaber, sri
In-Reply-To: <20071009020318.GA14708@gondor.apana.org.au>
On Tue, Oct 09, 2007 at 10:03:18AM +0800, Herbert Xu wrote:
> On Tue, Oct 09, 2007 at 10:01:15AM +0800, Herbert Xu wrote:
> > On Mon, Oct 08, 2007 at 06:41:26PM -0700, David Miller wrote:
> > >
> > > I also want to point out another issue. Any argument wrt. reordering
> > > is specious at best because right now reordering from qdisc to device
> > > happens anyways.
> >
> > This is not true.
> >
> > If your device has a qdisc at all, then you will end up in the
> > function qdisc_restart, where we release the queue lock only
> > after acquiring the TX lock.
> >
> > So right now this path does not create any reordering.
>
> Argh! Someone's just broken this. I think we should restore
> the original behaviour.
Please revert
commit 41843197b17bdfb1f97af0a87c06d24c1620ba90
Author: Jamal Hadi Salim <hadi@cyberus.ca>
Date: Tue Sep 25 19:27:13 2007 -0700
[NET_SCHED]: explict hold dev tx lock
As this change introduces potential reordering and I don't think
we've discussed this aspect sufficiently.
Thanks,
--
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
* [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Herbert Xu @ 2007-10-09 2:03 UTC (permalink / raw)
To: David Miller
Cc: johnpol, jeff, Robert.Olsson, netdev, rdreier,
peter.p.waskiewicz.jr, hadi, mcarlson, gaagaan, jagana, general,
mchan, tgraf, randy.dunlap, shemminger, kaber, sri
In-Reply-To: <20071009020115.GA14635@gondor.apana.org.au>
On Tue, Oct 09, 2007 at 10:01:15AM +0800, Herbert Xu wrote:
> On Mon, Oct 08, 2007 at 06:41:26PM -0700, David Miller wrote:
> >
> > I also want to point out another issue. Any argument wrt. reordering
> > is specious at best because right now reordering from qdisc to device
> > happens anyways.
>
> This is not true.
>
> If your device has a qdisc at all, then you will end up in the
> function qdisc_restart, where we release the queue lock only
> after acquiring the TX lock.
>
> So right now this path does not create any reordering.
Argh! Someone's just broken this. I think we should restore
the original behaviour.
Thanks,
--
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
* [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Herbert Xu @ 2007-10-09 2:01 UTC (permalink / raw)
To: David Miller
Cc: johnpol, jeff, Robert.Olsson, netdev, rdreier,
peter.p.waskiewicz.jr, hadi, mcarlson, gaagaan, jagana, general,
mchan, tgraf, randy.dunlap, shemminger, kaber, sri
In-Reply-To: <20071008.184126.124062865.davem@davemloft.net>
On Mon, Oct 08, 2007 at 06:41:26PM -0700, David Miller wrote:
>
> I also want to point out another issue. Any argument wrt. reordering
> is specious at best because right now reordering from qdisc to device
> happens anyways.
This is not true.
If your device has a qdisc at all, then you will end up in the
function qdisc_restart, where we release the queue lock only
after acquiring the TX lock.
So right now this path does not create any reordering.
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
* [ofa-general] Re: parallel networking
From: Jeff Garzik @ 2007-10-09 1:53 UTC (permalink / raw)
To: David Miller
Cc: randy.dunlap, Robert.Olsson, gaagaan, kumarkr,
peter.p.waskiewicz.jr, shemminger, johnpol, herbert, rdreier,
general, mingo, sri, jagana, hadi, mchan, netdev, linux-kernel,
tgraf, kaber
In-Reply-To: <20071008.141154.107706003.davem@davemloft.net>
David Miller wrote:
> From: Jeff Garzik <jeff@garzik.org>
> Date: Mon, 08 Oct 2007 10:22:28 -0400
>
>> In terms of overall parallelization, both for TX as well as RX, my gut
>> feeling is that we want to move towards an MSI-X, multi-core friendly
>> model where packets are LIKELY to be sent and received by the same set
>> of [cpus | cores | packages | nodes] that the [userland] processes
>> dealing with the data.
>
> The problem is that the packet schedulers want global guarantees
> on packet ordering, not flow centric ones.
>
> That is the issue Jamal is concerned about.
Oh, absolutely.
I think, fundamentally, any amount of cross-flow resource management
done in software is an obstacle to concurrency.
That's not a value judgement, just a statement of fact.
"traffic cops" are intentional bottlenecks we add to the process, to
enable features like priority flows, filtering, or even simple socket
fairness guarantees. Each of those bottlenecks serves a valid purpose,
but at the end of the day, it's still a bottleneck.
So, improving concurrency may require turning off useful features that
nonetheless hurt concurrency.
> The more I think about it, the more inevitable it seems that we really
> might need multiple qdiscs, one for each TX queue, to pull this full
> parallelization off.
>
> But the semantics of that don't smell so nice either. If the user
> attaches a new qdisc to "ethN", does it go to all the TX queues, or
> what?
>
> All of the traffic shaping technology deals with the device as a unary
> object. It doesn't fit to multi-queue at all.
Well the easy solutions to networking concurrency are
* use virtualization to carve up the machine into chunks
* use multiple net devices
Since new NIC hardware is actively trying to be friendly to
multi-channel/virt scenarios, either of these is reasonably
straightforward given the current state of the Linux net stack. Using
multiple net devices is especially attractive because it works very well
with the existing packet scheduling.
Both unfortunately impose a burden on the developer and admin, to force
their apps to distribute flows across multiple [VMs | net devs].
The third alternative is to use a single net device, with SMP-friendly
packet scheduling. Here you run into the problems you described "device
as a unary object" etc. with the current infrastructure.
With multiple TX rings, consider that we are pushing the packet
scheduling from software to hardware... which implies
* hardware-specific packet scheduling
* some TC/shaping features not available, because hardware doesn't
support it
Jeff
^ permalink raw reply
* [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: David Miller @ 2007-10-09 1:41 UTC (permalink / raw)
To: jeff
Cc: johnpol, herbert, gaagaan, Robert.Olsson, netdev, rdreier,
peter.p.waskiewicz.jr, hadi, mcarlson, jagana, general, mchan,
tgraf, randy.dunlap, sri, shemminger, kaber
In-Reply-To: <470AD5D7.1070000@garzik.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Mon, 08 Oct 2007 21:13:59 -0400
> If you assume a scheduler implementation where each prio band is mapped
> to a separate CPU, you can certainly see where some CPUs could be
> substantially idle while others are overloaded, largely depending on the
> data workload (and priority contained within).
Right, which is why Peter added the prio DRR scheduler stuff for TX
multiqueue (see net/sched/sch_prio.c:rr_qdisc_ops) because this is
what the chips do.
But this doesn't get us to where we want to be as Peter has been
explaining a bit these past few days.
Ok, we're talking a lot but not pouring much concrete, let's start
doing that. I propose:
1) A library for transmit load balancing functions, with an interface
that can be made visible to userspace. I can write this and test
it on real multiqueue hardware.
The whole purpose of this library is to set skb->queue_mapping
based upon the load balancing function.
Facilities will be added to handle virtualization port selection
based upon destination MAC address as one of the "load balancing"
methods.
2) Switch the default qdisc away from pfifo_fast to a new DRR fifo
with load balancing using the code in #1. I think this is kind
of in the territory of what Peter said he is working on.
I know this is controversial, but realistically I doubt users
benefit at all from the prioritization that pfifo provides. They
will, on the other hand, benefit from TX queue load balancing on
fast interfaces.
3) Work on discovering a way to make the locking on transmit as
localized to the current thread of execution as possible. Things
like RCU and statistic replication, techniques we use widely
elsewhere in the stack, begin to come to mind.
I also want to point out another issue. Any argument wrt. reordering
is specious at best because right now reordering from qdisc to device
happens anyways.
And that's because we drop the qdisc lock first, then we grab the
transmit lock on the device and submit the packet. So, after we
drop the qdisc lock, another cpu can get the qdisc lock, get the
next packet (perhaps a lower priority one) and then sneak in to
get the device transmit lock before the first thread can, and
thus the packets will be submitted out of order.
This, along with other things, makes me believe that ordering really
doesn't matter in practice. And therefore, in practice, we can treat
everything from the qdisc to the real hardware as a FIFO even if
something else is going on inside the black box which might reorder
packets on the wire.
^ permalink raw reply
* Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Jeff Garzik @ 2007-10-09 1:31 UTC (permalink / raw)
To: hadi
Cc: Waskiewicz Jr, Peter P, David Miller, krkumar2, johnpol, herbert,
kaber, shemminger, jagana, Robert.Olsson, rick.jones2, xma,
gaagaan, netdev, rdreier, mcarlson, mchan, general, tgraf,
randy.dunlap, sri
In-Reply-To: <1191886845.4373.138.camel@localhost>
jamal wrote:
> The challenge to deal with is that netdevices, filters, the queues and
> scheduler are closely inter-twined. So it is not just the scheduling
> region and QDISC_RUNNING. For example, lets pick just the filters
> because they are simple to see: You need to attach them to something -
> whatever that is, you then need to synchronize against config and
> multiple cpus trying to use them. You could:
> a) replicate them across cpus and only lock on config, but you are
> wasting RAM then
I think you've pretty much bought into the cost of wasting RAM, when
doing multiple TX rings. So logic implies associated costs, like the
ones you describe, come along for the ride.
> b) attach them to rings instead of netdevices - but that makes me wonder
> if those subqueues are now going to become netdevices. This also means
> you change all user space interfaces to know about subqueues. If you
> recall this was a major contention in our earlier discussion.
That's definitely a good question, and I honestly don't see any easy
solutions.
Multiple net devices makes a -lot- of things easier, with regards to
existing infrastructure, but it also imposes potentially annoying
administrative burdens: Not only must each interface be set up
individually, but the userland apps must be made aware of this unique
method of concurrency.
Jeff
^ permalink raw reply
* Re: [PATCH 3/7] [IPSEC]: Move common output code to xfrm_output
From: David Miller @ 2007-10-09 1:18 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20071009010257.GA14117@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 9 Oct 2007 09:02:57 +0800
> On Mon, Oct 08, 2007 at 05:17:17PM -0700, David Miller wrote:
> >
> > Could you submit a 2.6.23 version of just the ipv4 fix?
> > It might be interesting to determine why it was omitted,
> > perhaps it was an oversight, and it probably predates the
> > addition of skb_reset_*().
>
> OK I double-checked and it isn't necessary at all for IPv4 as
> the mode output function already sets the correct value in it.
>
> It's needed for IPv6 because the mode output functions there
> uses it to store a pointer to the NH pointer.
>
> So no changes are necessary.
Thanks for doing this research.
^ permalink raw reply
* Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Jeff Garzik @ 2007-10-09 1:13 UTC (permalink / raw)
To: hadi
Cc: Waskiewicz Jr, Peter P, David Miller, krkumar2, johnpol, herbert,
kaber, shemminger, jagana, Robert.Olsson, rick.jones2, xma,
gaagaan, netdev, rdreier, mcarlson, mchan, general, tgraf,
randy.dunlap, sri
In-Reply-To: <1191886845.4373.138.camel@localhost>
jamal wrote:
> Ok, so the "concurency" aspect is what worries me. What i am saying is
> that sooner or later you have to serialize (which is anti-concurency)
> For example, consider CPU0 running a high prio queue and CPU1 running
> the low prio queue of the same netdevice.
> Assume CPU0 is getting a lot of interupts or other work while CPU1
> doesnt (so as to create a condition that CPU1 is slower). Then as long
> as there packets and there is space on the drivers rings, CPU1 will send
> more packets per unit time than CPU0.
> This contradicts the strict prio scheduler which says higher priority
> packets ALWAYS go out first regardless of the presence of low prio
> packets. I am not sure i made sense.
You made sense. I think it is important to note simply that the packet
scheduling algorithm itself will dictate the level of concurrency you
can achieve.
Strict prio is fundamentally an interface to a big imaginary queue, with
multiple packet insertion points (the individual bands/rings for each
prio band).
If you assume a scheduler implementation where each prio band is mapped
to a separate CPU, you can certainly see where some CPUs could be
substantially idle while others are overloaded, largely depending on the
data workload (and priority contained within).
Moreover, you increase L1/L2 cache traffic, not just because of locks,
but because of data dependencies:
user prio packet NIC TX ring
process band scheduler
cpu7 1 cpu1 1
cpu5 1 cpu1 1
cpu2 0 cpu0 0
At that point, it is probably more cache- and lock-friendly to keep the
current TX softirq scheme.
In contrast, a pure round-robin approach is more friendly to concurrency.
Jeff
^ permalink raw reply
* Re: [PATCH 3/7] [IPSEC]: Move common output code to xfrm_output
From: Herbert Xu @ 2007-10-09 1:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20071008.171717.71577244.davem@davemloft.net>
On Mon, Oct 08, 2007 at 05:17:17PM -0700, David Miller wrote:
>
> Could you submit a 2.6.23 version of just the ipv4 fix?
> It might be interesting to determine why it was omitted,
> perhaps it was an oversight, and it probably predates the
> addition of skb_reset_*().
OK I double-checked and it isn't necessary at all for IPv4 as
the mode output function already sets the correct value in it.
It's needed for IPv6 because the mode output functions there
uses it to store a pointer to the NH pointer.
So no changes are necessary.
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 1/8][BNX2X] resubmit as attachments: add bnx2x to Kconfig and Makefile
From: David Miller @ 2007-10-09 0:46 UTC (permalink / raw)
To: eliezert; +Cc: jeff, netdev, mchan
In-Reply-To: <470A5795.2000809@broadcom.com>
From: "Eliezer Tamir" <eliezert@broadcom.com>
Date: Mon, 08 Oct 2007 18:15:17 +0200
> Add bnx2x to Kconfig and Makefile
In a patch submission, the tree should build on every step along the
way in applying your patches, with any given configuration.
Here, the user (or something automated like "make allmodconfig") can
select the new config option, but because the driver source hasn't
been added, the compile will fail.
The idea is that if your patch set really is composed of logically
seperate changes, you submit them one logical compilable piece at a
time, and if the first few patches are ok, they could go right in
whilst we work out issues in later patches. But that's not how
a new driver is, it is logically one change only.
You go on next to add a foo.c file, and then a foo.h file.
This makes things even more difficult to review.
Really, for a new driver that doesn't make any generic kernel code
changes, just submit the whole thing in one shot. It's the only
reasonable way.
Thank you.
^ permalink raw reply
* Re: [0/7] IPsec: Preparatory patcheds for async crypto on output
From: David Miller @ 2007-10-09 0:28 UTC (permalink / raw)
To: johnpol; +Cc: herbert, netdev
In-Reply-To: <20071008122034.GA23718@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Mon, 8 Oct 2007 16:20:40 +0400
> Dave, is there any chance it can be accepted for upcoming release?
Does a Russian drink vodka? :-)
I'm certainly willing to entertain the idea.
^ permalink raw reply
* Re: [PATCH 7/7] [IPSEC]: Move RO-specific output code into xfrm6_mode_ro.c
From: David Miller @ 2007-10-09 0:27 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1Ieqnw-0000oO-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 08 Oct 2007 19:29:44 +0800
> [IPSEC]: Move RO-specific output code into xfrm6_mode_ro.c
>
> The lastused update check in xfrm_output can be done just as well in
> the mode output function which is specific to RO.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Also applied, thanks Herbert!
^ permalink raw reply
* Re: [PATCH 6/7] [IPSEC]: Unexport xfrm_replay_notify
From: David Miller @ 2007-10-09 0:26 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1Ieqnv-0000oK-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 08 Oct 2007 19:29:43 +0800
> [IPSEC]: Unexport xfrm_replay_notify
>
> Now that the only callers of xfrm_replay_notify are in xfrm, we can remove
> the export.
>
> This patch also removes xfrm_aevent_doreplay since it's now called in just
> one spot.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: [PATCH 5/7] [IPSEC]: Move output replay code into xfrm_output
From: David Miller @ 2007-10-09 0:26 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1Ieqnu-0000oF-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 08 Oct 2007 19:29:42 +0800
> [IPSEC]: Move output replay code into xfrm_output
>
> The replay counter is one of only two remaining things in the output code
> that requires a lock on the xfrm state (the other being the crypto). This
> patch moves it into the generic xfrm_output so we can remove the lock from
> the transforms themselves.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: [PATCH 4/7] [IPSEC]: Move xfrm_state_check into xfrm_output.c
From: David Miller @ 2007-10-09 0:25 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1Ieqnt-0000oB-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 08 Oct 2007 19:29:41 +0800
> [IPSEC]: Move xfrm_state_check into xfrm_output.c
>
> The functions xfrm_state_check and xfrm_state_check_space are only used by
> the output code in xfrm_output.c so we can move them over.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied :)
^ permalink raw reply
* Re: [PATCH 3/7] [IPSEC]: Move common output code to xfrm_output
From: David Miller @ 2007-10-09 0:17 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1Ieqnr-0000o7-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 08 Oct 2007 19:29:39 +0800
> [IPSEC]: Move common output code to xfrm_output
>
> Most of the code in xfrm4_output_one and xfrm6_output_one are identical so
> this patch moves them into a common xfrm_output function which will live
> in net/xfrm.
>
> In fact this would seem to fix a bug as on IPv4 we never reset the network
> header after a transform which may upset netfilter later on.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
Could you submit a 2.6.23 version of just the ipv4 fix?
It might be interesting to determine why it was omitted,
perhaps it was an oversight, and it probably predates the
addition of skb_reset_*().
^ permalink raw reply
* Re: [PATCH 2/7] [IPSEC] ah: Remove keys from ah_data structure
From: David Miller @ 2007-10-09 0:14 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1Ieqnq-0000o3-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 08 Oct 2007 19:29:38 +0800
> [IPSEC] ah: Remove keys from ah_data structure
>
> The keys are only used during initialisation so we don't need to carry them
> in esp_data. Since we don't have to allocate them again, there is no need
> to place a limit on the authentication key length anymore.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
And if I liked the ESP side, how can I not like this patch :-)
Also applied, thanks Herbert!
^ permalink raw reply
* Re: [PATCH 1/7] [IPSEC] esp: Remove keys from esp_data structure
From: David Miller @ 2007-10-09 0:14 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1Ieqnp-0000nz-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 08 Oct 2007 19:29:37 +0800
> [IPSEC] esp: Remove keys from esp_data structure
>
> The keys are only used during initialisation so we don't need to carry them
> in esp_data. Since we don't have to allocate them again, there is no need
> to place a limit on the authentication key length anymore.
>
> This patch also kills the unused auth.icv member.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Nice cleanup, patch applied, thanks!
^ permalink raw reply
* Re: Fixed PHY regression
From: Jeff Garzik @ 2007-10-08 23:56 UTC (permalink / raw)
To: David Miller; +Cc: joakim.tjernlund, netdev
In-Reply-To: <20071008.142057.31775797.davem@davemloft.net>
David Miller wrote:
> From: "Joakim Tjernlund" <joakim.tjernlund@transmode.se>
> Date: Mon, 8 Oct 2007 20:17:33 +0200
>
>> David, any chance the second item, Oops while modprobing phy fixed module, in
>> http://marc.info/?l=linux-kernel&m=119178673421891&w=2
>> will make it into 2.6.23?
>>
>> The fix is now in your tree,
>> http://git.kernel.org/?p=linux/kernel/git/davem/bak-net-2.6.24.git;a=commit;h=bbb4c0c35a4c2aed5e025b668c8dfc99c5b74cff
>>
>> It has been in Andrews tree for a while, then in Garzik and now it is in your tree.
>
> Jeff, any reason you didn't submit this one for 2.6.23?
Two reasons:
* despite the subject, after discussion it looked like a problem with
module release, making "build it into your kernel" a valid workaround
* the fix was quite invasive this late in the game
If people still think it should go for 2.6.23, that's cool with me.
Jeff
^ permalink raw reply
* [ofa-general] Re: parallel networking
From: jamal @ 2007-10-08 23:42 UTC (permalink / raw)
To: David Miller
Cc: randy.dunlap, Robert.Olsson, gaagaan, kumarkr,
peter.p.waskiewicz.jr, shemminger, johnpol, herbert, jeff,
rdreier, general, mingo, sri, jagana, mchan, netdev, linux-kernel,
tgraf, kaber
In-Reply-To: <20071008.153353.58431888.davem@davemloft.net>
On Mon, 2007-08-10 at 15:33 -0700, David Miller wrote:
> Multiply whatever effect you think you might be able to measure due to
> that on your 2 or 4 way system, and multiple it up to 64 cpus or so
> for machines I am using. This is where machines are going, and is
> going to become the norm.
Yes, i keep forgetting that ;-> I need to train my brain to remember
that.
cheers,
jamal
^ permalink raw reply
* RE: [PATCH 2/3][NET_BATCH] net core use batching
From: jamal @ 2007-10-08 23:40 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P
Cc: David Miller, krkumar2, johnpol, herbert, kaber, shemminger,
jagana, Robert.Olsson, rick.jones2, xma, gaagaan, netdev, rdreier,
mcarlson, jeff, mchan, general, tgraf, randy.dunlap, sri
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC32903BC14AC@orsmsx414.amr.corp.intel.com>
On Mon, 2007-08-10 at 15:33 -0700, Waskiewicz Jr, Peter P wrote:
> Addressing your note/issue with different rings being services
> concurrently: I'd like to remove the QDISC_RUNNING bit from the global
The challenge to deal with is that netdevices, filters, the queues and
scheduler are closely inter-twined. So it is not just the scheduling
region and QDISC_RUNNING. For example, lets pick just the filters
because they are simple to see: You need to attach them to something -
whatever that is, you then need to synchronize against config and
multiple cpus trying to use them. You could:
a) replicate them across cpus and only lock on config, but you are
wasting RAM then
b) attach them to rings instead of netdevices - but that makes me wonder
if those subqueues are now going to become netdevices. This also means
you change all user space interfaces to know about subqueues. If you
recall this was a major contention in our earlier discussion.
> device; with Tx multiqueue, this bit should be set on each queue (if at
> all), allowing multiple Tx rings to be loaded simultaneously.
This is the issue i raised - refer to Dave's wording of it. If you run
access to the rings simultenously you may not be able to guarantee any
ordering or proper qos in contention for wire-resources (think strict
prio in hardware) - as long as you have the qdisc area. You may
actually get away with it with something like DRR.
You could totaly bypass the qdisc region and go to the driver directly
and let it worry about the scheduling but youd have to make the qdisc
area a "passthrough" while providing the illusion to user space that all
is as before.
> The
> biggest issue today with the multiqueue implementation is the global
> queue_lock. I see it being a hot source of contention in my testing; my
> setup is a 8-core machine (dual quad-core procs) with a 10GbE NIC, using
> 8 Tx and 8 Rx queues. On transmit, when loading all 8 queues, the
> enqueue/dequeue are hitting that lock quite a bit for the whole device.
Yes, the queuelock is expensive; in your case if all 8 hardware threads
are contending for that one device, you will suffer. The txlock on the
other hand is not that expensive since the contention is for a max of 2
cpus (tx and rx softirq).
I tried to use that fact in the batching to move things that i processed
under queue lock into the area for txlock. I'd be very interested in
some results on such a piece of hardware with the 10G nic to see if
these theories make any sense.
> I really think that the queue_lock should join the queue_state, so the
> device no longer manages the top-level state (since we're operating
> per-queue instead of per-device).
Refer to above.
>
> The multiqueue implementation today enforces the number of qdisc bands
> (RR or PRIO) to be equal to the number of Tx rings your hardware/driver
> is supporting. Therefore, the queue_lock and queue_state in the kernel
> directly relate to the qdisc band management. If the queue stops from
> the driver, then the qdisc won't try to dequeue from the band.
Good start.
> What I'm
> working on is to move the lock there too, so I can lock the queue when I
> enqueue (protect the band from multiple sources modifying the skb
> chain), and lock it when I dequeue. This is purely for concurrency of
> adding/popping skb's from the qdisc queues.
Ok, so the "concurency" aspect is what worries me. What i am saying is
that sooner or later you have to serialize (which is anti-concurency)
For example, consider CPU0 running a high prio queue and CPU1 running
the low prio queue of the same netdevice.
Assume CPU0 is getting a lot of interupts or other work while CPU1
doesnt (so as to create a condition that CPU1 is slower). Then as long
as there packets and there is space on the drivers rings, CPU1 will send
more packets per unit time than CPU0.
This contradicts the strict prio scheduler which says higher priority
packets ALWAYS go out first regardless of the presence of low prio
packets. I am not sure i made sense.
cheers,
jamal
^ permalink raw reply
* [PATCH net-2.6.24] cxgb3 sparse warning fixes
From: Stephen Hemminger @ 2007-10-08 23:22 UTC (permalink / raw)
To: Divy Le Ray, David S. Miller, Jeff Garzik; +Cc: netdev
Fix warnings from sparse related to shadowed variables and routines
that should be declared static.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
---
CHECK drivers/net/cxgb3/cxgb3_main.c
drivers/net/cxgb3/cxgb3_main.c:1773:20: warning: symbol 'pi' shadows an earlier one
drivers/net/cxgb3/cxgb3_main.c:1664:19: originally declared here
drivers/net/cxgb3/cxgb3_main.c:1805:20: warning: symbol 'pi' shadows an earlier one
drivers/net/cxgb3/cxgb3_main.c:1664:19: originally declared here
drivers/net/cxgb3/cxgb3_main.c:743:5: warning: symbol 'update_tpsram' was not declared. Should it be static?
CHECK drivers/net/cxgb3/t3_hw.c
drivers/net/cxgb3/t3_hw.c:122:6: warning: symbol 't3_read_indirect' was not declared. Should it be static?
drivers/net/cxgb3/t3_hw.c:3410:5: warning: symbol 't3_reset_adapter' was not declared. Should it be static?
CHECK drivers/net/cxgb3/xgmac.c
drivers/net/cxgb3/xgmac.c:145:5: warning: symbol 't3b2_mac_reset' was not declared. Should it be static?
CHECK drivers/net/cxgb3/sge.c
include/linux/mm.h:587:9: warning: potentially expensive pointer subtraction
drivers/net/cxgb3/sge.c:547:6: warning: symbol 't3_free_qset' was not declared. Should it be static?
include/linux/mm.h:587:9: warning: potentially expensive pointer subtraction
include/linux/mm.h:587:9: warning: potentially expensive pointer subtraction
drivers/net/cxgb3/sge.c:2218:13: warning: symbol 't3_sge_intr_msix_napi' was not declared. Should it be static?
drivers/net/cxgb3/sge.c:2287:13: warning: symbol 't3_intr_msi_napi' was not declared. Should it be static?
CHECK drivers/net/cxgb3/cxgb3_offload.c
drivers/net/cxgb3/cxgb3_offload.c:226:20: warning: symbol 'req' shadows an earlier one
drivers/net/cxgb3/cxgb3_offload.c:220:64: originally declared here
drivers/net/cxgb3/cxgb3_offload.c:245:21: warning: symbol 'req' shadows an earlier one
drivers/net/cxgb3/cxgb3_offload.c:220:64: originally declared here
drivers/net/cxgb3/cxgb3_offload.c:277:24: warning: symbol 'req' shadows an earlier one
drivers/net/cxgb3/cxgb3_offload.c:220:64: originally declared here
drivers/net/cxgb3/cxgb3_offload.c:295:28: warning: symbol 'req' shadows an earlier one
drivers/net/cxgb3/cxgb3_offload.c:220:64: originally declared here
drivers/net/cxgb3/cxgb3_main.c | 4 ---
drivers/net/cxgb3/cxgb3_offload.c | 44 +++++++++++++++++++-------------------
drivers/net/cxgb3/sge.c | 6 ++---
drivers/net/cxgb3/t3_hw.c | 8 +++---
drivers/net/cxgb3/xgmac.c | 2 -
5 files changed, 31 insertions(+), 33 deletions(-)
--- a/drivers/net/cxgb3/cxgb3_main.c 2007-10-08 15:34:39.000000000 -0700
+++ b/drivers/net/cxgb3/cxgb3_main.c 2007-10-08 16:10:45.000000000 -0700
@@ -740,7 +740,7 @@ static inline char t3rev2char(struct ada
return rev;
}
-int update_tpsram(struct adapter *adap)
+static int update_tpsram(struct adapter *adap)
{
const struct firmware *tpsram;
char buf[64];
@@ -1770,7 +1770,6 @@ static int cxgb_extension_ioctl(struct n
}
case CHELSIO_SET_QSET_NUM:{
struct ch_reg edata;
- struct port_info *pi = netdev_priv(dev);
unsigned int i, first_qset = 0, other_qsets = 0;
if (!capable(CAP_NET_ADMIN))
@@ -1802,7 +1801,6 @@ static int cxgb_extension_ioctl(struct n
}
case CHELSIO_GET_QSET_NUM:{
struct ch_reg edata;
- struct port_info *pi = netdev_priv(dev);
edata.cmd = CHELSIO_GET_QSET_NUM;
edata.val = pi->nqsets;
--- a/drivers/net/cxgb3/cxgb3_offload.c 2007-10-04 09:33:28.000000000 -0700
+++ b/drivers/net/cxgb3/cxgb3_offload.c 2007-10-08 16:13:03.000000000 -0700
@@ -222,32 +222,32 @@ static int cxgb_rdma_ctl(struct adapter
int ret = 0;
switch (req) {
- case RDMA_GET_PARAMS:{
- struct rdma_info *req = data;
+ case RDMA_GET_PARAMS: {
+ struct rdma_info *rdma = data;
struct pci_dev *pdev = adapter->pdev;
- req->udbell_physbase = pci_resource_start(pdev, 2);
- req->udbell_len = pci_resource_len(pdev, 2);
- req->tpt_base =
+ rdma->udbell_physbase = pci_resource_start(pdev, 2);
+ rdma->udbell_len = pci_resource_len(pdev, 2);
+ rdma->tpt_base =
t3_read_reg(adapter, A_ULPTX_TPT_LLIMIT);
- req->tpt_top = t3_read_reg(adapter, A_ULPTX_TPT_ULIMIT);
- req->pbl_base =
+ rdma->tpt_top = t3_read_reg(adapter, A_ULPTX_TPT_ULIMIT);
+ rdma->pbl_base =
t3_read_reg(adapter, A_ULPTX_PBL_LLIMIT);
- req->pbl_top = t3_read_reg(adapter, A_ULPTX_PBL_ULIMIT);
- req->rqt_base = t3_read_reg(adapter, A_ULPRX_RQ_LLIMIT);
- req->rqt_top = t3_read_reg(adapter, A_ULPRX_RQ_ULIMIT);
- req->kdb_addr = adapter->regs + A_SG_KDOORBELL;
- req->pdev = pdev;
+ rdma->pbl_top = t3_read_reg(adapter, A_ULPTX_PBL_ULIMIT);
+ rdma->rqt_base = t3_read_reg(adapter, A_ULPRX_RQ_LLIMIT);
+ rdma->rqt_top = t3_read_reg(adapter, A_ULPRX_RQ_ULIMIT);
+ rdma->kdb_addr = adapter->regs + A_SG_KDOORBELL;
+ rdma->pdev = pdev;
break;
}
case RDMA_CQ_OP:{
unsigned long flags;
- struct rdma_cq_op *req = data;
+ struct rdma_cq_op *rdma = data;
/* may be called in any context */
spin_lock_irqsave(&adapter->sge.reg_lock, flags);
- ret = t3_sge_cqcntxt_op(adapter, req->id, req->op,
- req->credits);
+ ret = t3_sge_cqcntxt_op(adapter, rdma->id, rdma->op,
+ rdma->credits);
spin_unlock_irqrestore(&adapter->sge.reg_lock, flags);
break;
}
@@ -274,15 +274,15 @@ static int cxgb_rdma_ctl(struct adapter
break;
}
case RDMA_CQ_SETUP:{
- struct rdma_cq_setup *req = data;
+ struct rdma_cq_setup *rdma = data;
spin_lock_irq(&adapter->sge.reg_lock);
ret =
- t3_sge_init_cqcntxt(adapter, req->id,
- req->base_addr, req->size,
+ t3_sge_init_cqcntxt(adapter, rdma->id,
+ rdma->base_addr, rdma->size,
ASYNC_NOTIF_RSPQ,
- req->ovfl_mode, req->credits,
- req->credit_thres);
+ rdma->ovfl_mode, rdma->credits,
+ rdma->credit_thres);
spin_unlock_irq(&adapter->sge.reg_lock);
break;
}
@@ -292,13 +292,13 @@ static int cxgb_rdma_ctl(struct adapter
spin_unlock_irq(&adapter->sge.reg_lock);
break;
case RDMA_CTRL_QP_SETUP:{
- struct rdma_ctrlqp_setup *req = data;
+ struct rdma_ctrlqp_setup *rdma = data;
spin_lock_irq(&adapter->sge.reg_lock);
ret = t3_sge_init_ecntxt(adapter, FW_RI_SGEEC_START, 0,
SGE_CNTXT_RDMA,
ASYNC_NOTIF_RSPQ,
- req->base_addr, req->size,
+ rdma->base_addr, rdma->size,
FW_RI_TID_START, 1, 0);
spin_unlock_irq(&adapter->sge.reg_lock);
break;
--- a/drivers/net/cxgb3/sge.c 2007-10-08 15:35:18.000000000 -0700
+++ b/drivers/net/cxgb3/sge.c 2007-10-08 16:11:57.000000000 -0700
@@ -544,7 +544,7 @@ static void *alloc_ring(struct pci_dev *
* as HW contexts, packet buffers, and descriptor rings. Traffic to the
* queue set must be quiesced prior to calling this.
*/
-void t3_free_qset(struct adapter *adapter, struct sge_qset *q)
+static void t3_free_qset(struct adapter *adapter, struct sge_qset *q)
{
int i;
struct pci_dev *pdev = adapter->pdev;
@@ -2215,7 +2215,7 @@ irqreturn_t t3_sge_intr_msix(int irq, vo
* The MSI-X interrupt handler for an SGE response queue for the NAPI case
* (i.e., response queue serviced by NAPI polling).
*/
-irqreturn_t t3_sge_intr_msix_napi(int irq, void *cookie)
+static irqreturn_t t3_sge_intr_msix_napi(int irq, void *cookie)
{
struct sge_qset *qs = cookie;
struct sge_rspq *q = &qs->rspq;
@@ -2284,7 +2284,7 @@ static int rspq_check_napi(struct sge_qs
* one SGE response queue per port in this mode and protect all response
* queues with queue 0's lock.
*/
-irqreturn_t t3_intr_msi_napi(int irq, void *cookie)
+static irqreturn_t t3_intr_msi_napi(int irq, void *cookie)
{
int new_packets;
struct adapter *adap = cookie;
--- a/drivers/net/cxgb3/t3_hw.c 2007-10-04 09:33:28.000000000 -0700
+++ b/drivers/net/cxgb3/t3_hw.c 2007-10-08 16:11:24.000000000 -0700
@@ -119,9 +119,9 @@ void t3_set_reg_field(struct adapter *ad
* Reads registers that are accessed indirectly through an address/data
* register pair.
*/
-void t3_read_indirect(struct adapter *adap, unsigned int addr_reg,
- unsigned int data_reg, u32 *vals, unsigned int nregs,
- unsigned int start_idx)
+static void t3_read_indirect(struct adapter *adap, unsigned int addr_reg,
+ unsigned int data_reg, u32 *vals,
+ unsigned int nregs, unsigned int start_idx)
{
while (nregs--) {
t3_write_reg(adap, addr_reg, start_idx);
@@ -3407,7 +3407,7 @@ void early_hw_init(struct adapter *adapt
* Older PCIe cards lose their config space during reset, PCI-X
* ones don't.
*/
-int t3_reset_adapter(struct adapter *adapter)
+static int t3_reset_adapter(struct adapter *adapter)
{
int i, save_and_restore_pcie =
adapter->params.rev < T3_REV_B2 && is_pcie(adapter);
--- a/drivers/net/cxgb3/xgmac.c 2007-10-04 09:33:28.000000000 -0700
+++ b/drivers/net/cxgb3/xgmac.c 2007-10-08 16:11:34.000000000 -0700
@@ -142,7 +142,7 @@ int t3_mac_reset(struct cmac *mac)
return 0;
}
-int t3b2_mac_reset(struct cmac *mac)
+static int t3b2_mac_reset(struct cmac *mac)
{
struct adapter *adap = mac->adapter;
unsigned int oft = mac->offset;
^ permalink raw reply
* [PATCH net-2.6.24] chelsio: sparse warning fixes (old cxgb2)
From: Stephen Hemminger @ 2007-10-08 23:19 UTC (permalink / raw)
To: Jeff Garzik, David S. Miller; +Cc: netdev, Divy Le Ray
Fix problems detected by sparse:
1. whole chunk of MAC code was for defined and never used
2. hook for running ext intr in workqueue wasn't being used
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/chelsio/Makefile 2007-10-04 09:33:28.000000000 -0700
+++ b/drivers/net/chelsio/Makefile 2007-10-08 16:06:05.000000000 -0700
@@ -4,6 +4,6 @@
obj-$(CONFIG_CHELSIO_T1) += cxgb.o
-cxgb-$(CONFIG_CHELSIO_T1_1G) += mac.o mv88e1xxx.o vsc7326.o
+cxgb-$(CONFIG_CHELSIO_T1_1G) += mv88e1xxx.o vsc7326.o
cxgb-objs := cxgb2.o espi.o tp.o pm3393.o sge.o subr.o \
mv88x201x.o my3126.o $(cxgb-y)
--- a/drivers/net/chelsio/common.h 2007-10-04 09:33:28.000000000 -0700
+++ b/drivers/net/chelsio/common.h 2007-10-08 16:04:50.000000000 -0700
@@ -372,6 +372,7 @@ extern void t1_interrupts_enable(adapter
extern void t1_interrupts_disable(adapter_t *adapter);
extern void t1_interrupts_clear(adapter_t *adapter);
extern int t1_elmer0_ext_intr_handler(adapter_t *adapter);
+extern void t1_elmer0_ext_intr(adapter_t *adapter);
extern int t1_slow_intr_handler(adapter_t *adapter);
extern int t1_link_start(struct cphy *phy, struct cmac *mac, struct link_config *lc);
--- a/drivers/net/chelsio/mac.c 2007-10-08 16:06:32.000000000 -0700
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,368 +0,0 @@
-/* $Date: 2005/10/22 00:42:59 $ $RCSfile: mac.c,v $ $Revision: 1.32 $ */
-#include "gmac.h"
-#include "regs.h"
-#include "fpga_defs.h"
-
-#define MAC_CSR_INTERFACE_GMII 0x0
-#define MAC_CSR_INTERFACE_TBI 0x1
-#define MAC_CSR_INTERFACE_MII 0x2
-#define MAC_CSR_INTERFACE_RMII 0x3
-
-/* Chelsio's MAC statistics. */
-struct mac_statistics {
-
- /* Transmit */
- u32 TxFramesTransmittedOK;
- u32 TxReserved1;
- u32 TxReserved2;
- u32 TxOctetsTransmittedOK;
- u32 TxFramesWithDeferredXmissions;
- u32 TxLateCollisions;
- u32 TxFramesAbortedDueToXSCollisions;
- u32 TxFramesLostDueToIntMACXmitError;
- u32 TxReserved3;
- u32 TxMulticastFrameXmittedOK;
- u32 TxBroadcastFramesXmittedOK;
- u32 TxFramesWithExcessiveDeferral;
- u32 TxPAUSEMACCtrlFramesTransmitted;
-
- /* Receive */
- u32 RxFramesReceivedOK;
- u32 RxFrameCheckSequenceErrors;
- u32 RxAlignmentErrors;
- u32 RxOctetsReceivedOK;
- u32 RxFramesLostDueToIntMACRcvError;
- u32 RxMulticastFramesReceivedOK;
- u32 RxBroadcastFramesReceivedOK;
- u32 RxInRangeLengthErrors;
- u32 RxTxOutOfRangeLengthField;
- u32 RxFrameTooLongErrors;
- u32 RxPAUSEMACCtrlFramesReceived;
-};
-
-static int static_aPorts[] = {
- FPGA_GMAC_INTERRUPT_PORT0,
- FPGA_GMAC_INTERRUPT_PORT1,
- FPGA_GMAC_INTERRUPT_PORT2,
- FPGA_GMAC_INTERRUPT_PORT3
-};
-
-struct _cmac_instance {
- u32 index;
-};
-
-static int mac_intr_enable(struct cmac *mac)
-{
- u32 mac_intr;
-
- if (t1_is_asic(mac->adapter)) {
- /* ASIC */
-
- /* We don't use the on chip MAC for ASIC products. */
- } else {
- /* FPGA */
-
- /* Set parent gmac interrupt. */
- mac_intr = readl(mac->adapter->regs + A_PL_ENABLE);
- mac_intr |= FPGA_PCIX_INTERRUPT_GMAC;
- writel(mac_intr, mac->adapter->regs + A_PL_ENABLE);
-
- mac_intr = readl(mac->adapter->regs + FPGA_GMAC_ADDR_INTERRUPT_ENABLE);
- mac_intr |= static_aPorts[mac->instance->index];
- writel(mac_intr,
- mac->adapter->regs + FPGA_GMAC_ADDR_INTERRUPT_ENABLE);
- }
-
- return 0;
-}
-
-static int mac_intr_disable(struct cmac *mac)
-{
- u32 mac_intr;
-
- if (t1_is_asic(mac->adapter)) {
- /* ASIC */
-
- /* We don't use the on chip MAC for ASIC products. */
- } else {
- /* FPGA */
-
- /* Set parent gmac interrupt. */
- mac_intr = readl(mac->adapter->regs + A_PL_ENABLE);
- mac_intr &= ~FPGA_PCIX_INTERRUPT_GMAC;
- writel(mac_intr, mac->adapter->regs + A_PL_ENABLE);
-
- mac_intr = readl(mac->adapter->regs + FPGA_GMAC_ADDR_INTERRUPT_ENABLE);
- mac_intr &= ~(static_aPorts[mac->instance->index]);
- writel(mac_intr,
- mac->adapter->regs + FPGA_GMAC_ADDR_INTERRUPT_ENABLE);
- }
-
- return 0;
-}
-
-static int mac_intr_clear(struct cmac *mac)
-{
- u32 mac_intr;
-
- if (t1_is_asic(mac->adapter)) {
- /* ASIC */
-
- /* We don't use the on chip MAC for ASIC products. */
- } else {
- /* FPGA */
-
- /* Set parent gmac interrupt. */
- writel(FPGA_PCIX_INTERRUPT_GMAC,
- mac->adapter->regs + A_PL_CAUSE);
- mac_intr = readl(mac->adapter->regs + FPGA_GMAC_ADDR_INTERRUPT_CAUSE);
- mac_intr |= (static_aPorts[mac->instance->index]);
- writel(mac_intr,
- mac->adapter->regs + FPGA_GMAC_ADDR_INTERRUPT_CAUSE);
- }
-
- return 0;
-}
-
-static int mac_get_address(struct cmac *mac, u8 addr[6])
-{
- u32 data32_lo, data32_hi;
-
- data32_lo = readl(mac->adapter->regs
- + MAC_REG_IDLO(mac->instance->index));
- data32_hi = readl(mac->adapter->regs
- + MAC_REG_IDHI(mac->instance->index));
-
- addr[0] = (u8) ((data32_hi >> 8) & 0xFF);
- addr[1] = (u8) ((data32_hi) & 0xFF);
- addr[2] = (u8) ((data32_lo >> 24) & 0xFF);
- addr[3] = (u8) ((data32_lo >> 16) & 0xFF);
- addr[4] = (u8) ((data32_lo >> 8) & 0xFF);
- addr[5] = (u8) ((data32_lo) & 0xFF);
- return 0;
-}
-
-static int mac_reset(struct cmac *mac)
-{
- u32 data32;
- int mac_in_reset, time_out = 100;
- int idx = mac->instance->index;
-
- data32 = readl(mac->adapter->regs + MAC_REG_CSR(idx));
- writel(data32 | F_MAC_RESET,
- mac->adapter->regs + MAC_REG_CSR(idx));
-
- do {
- data32 = readl(mac->adapter->regs + MAC_REG_CSR(idx));
-
- mac_in_reset = data32 & F_MAC_RESET;
- if (mac_in_reset)
- udelay(1);
- } while (mac_in_reset && --time_out);
-
- if (mac_in_reset) {
- CH_ERR("%s: MAC %d reset timed out\n",
- mac->adapter->name, idx);
- return 2;
- }
-
- return 0;
-}
-
-static int mac_set_rx_mode(struct cmac *mac, struct t1_rx_mode *rm)
-{
- u32 val;
-
- val = readl(mac->adapter->regs
- + MAC_REG_CSR(mac->instance->index));
- val &= ~(F_MAC_PROMISC | F_MAC_MC_ENABLE);
- val |= V_MAC_PROMISC(t1_rx_mode_promisc(rm) != 0);
- val |= V_MAC_MC_ENABLE(t1_rx_mode_allmulti(rm) != 0);
- writel(val,
- mac->adapter->regs + MAC_REG_CSR(mac->instance->index));
-
- return 0;
-}
-
-static int mac_set_speed_duplex_fc(struct cmac *mac, int speed, int duplex,
- int fc)
-{
- u32 data32;
-
- data32 = readl(mac->adapter->regs
- + MAC_REG_CSR(mac->instance->index));
- data32 &= ~(F_MAC_HALF_DUPLEX | V_MAC_SPEED(M_MAC_SPEED) |
- V_INTERFACE(M_INTERFACE) | F_MAC_TX_PAUSE_ENABLE |
- F_MAC_RX_PAUSE_ENABLE);
-
- switch (speed) {
- case SPEED_10:
- case SPEED_100:
- data32 |= V_INTERFACE(MAC_CSR_INTERFACE_MII);
- data32 |= V_MAC_SPEED(speed == SPEED_10 ? 0 : 1);
- break;
- case SPEED_1000:
- data32 |= V_INTERFACE(MAC_CSR_INTERFACE_GMII);
- data32 |= V_MAC_SPEED(2);
- break;
- }
-
- if (duplex >= 0)
- data32 |= V_MAC_HALF_DUPLEX(duplex == DUPLEX_HALF);
-
- if (fc >= 0) {
- data32 |= V_MAC_RX_PAUSE_ENABLE((fc & PAUSE_RX) != 0);
- data32 |= V_MAC_TX_PAUSE_ENABLE((fc & PAUSE_TX) != 0);
- }
-
- writel(data32,
- mac->adapter->regs + MAC_REG_CSR(mac->instance->index));
- return 0;
-}
-
-static int mac_enable(struct cmac *mac, int which)
-{
- u32 val;
-
- val = readl(mac->adapter->regs
- + MAC_REG_CSR(mac->instance->index));
- if (which & MAC_DIRECTION_RX)
- val |= F_MAC_RX_ENABLE;
- if (which & MAC_DIRECTION_TX)
- val |= F_MAC_TX_ENABLE;
- writel(val,
- mac->adapter->regs + MAC_REG_CSR(mac->instance->index));
- return 0;
-}
-
-static int mac_disable(struct cmac *mac, int which)
-{
- u32 val;
-
- val = readl(mac->adapter->regs
- + MAC_REG_CSR(mac->instance->index));
- if (which & MAC_DIRECTION_RX)
- val &= ~F_MAC_RX_ENABLE;
- if (which & MAC_DIRECTION_TX)
- val &= ~F_MAC_TX_ENABLE;
- writel(val,
- mac->adapter->regs + MAC_REG_CSR(mac->instance->index));
- return 0;
-}
-
-#if 0
-static int mac_set_ifs(struct cmac *mac, u32 mode)
-{
- t1_write_reg_4(mac->adapter,
- MAC_REG_IFS(mac->instance->index),
- mode);
- return 0;
-}
-
-static int mac_enable_isl(struct cmac *mac)
-{
- u32 data32 = readl(mac->adapter->regs
- + MAC_REG_CSR(mac->instance->index));
- data32 |= F_MAC_RX_ENABLE | F_MAC_TX_ENABLE;
- t1_write_reg_4(mac->adapter,
- MAC_REG_CSR(mac->instance->index),
- data32);
- return 0;
-}
-#endif
-
-static int mac_set_mtu(struct cmac *mac, int mtu)
-{
- if (mtu > 9600)
- return -EINVAL;
- writel(mtu + ETH_HLEN + VLAN_HLEN,
- mac->adapter->regs + MAC_REG_LARGEFRAMELENGTH(mac->instance->index));
-
- return 0;
-}
-
-static const struct cmac_statistics *mac_update_statistics(struct cmac *mac,
- int flag)
-{
- struct mac_statistics st;
- u32 *p = (u32 *) & st, i;
-
- writel(0,
- mac->adapter->regs + MAC_REG_RMCNT(mac->instance->index));
-
- for (i = 0; i < sizeof(st) / sizeof(u32); i++)
- *p++ = readl(mac->adapter->regs
- + MAC_REG_RMDATA(mac->instance->index));
-
- /* XXX convert stats */
- return &mac->stats;
-}
-
-static void mac_destroy(struct cmac *mac)
-{
- kfree(mac);
-}
-
-static struct cmac_ops chelsio_mac_ops = {
- .destroy = mac_destroy,
- .reset = mac_reset,
- .interrupt_enable = mac_intr_enable,
- .interrupt_disable = mac_intr_disable,
- .interrupt_clear = mac_intr_clear,
- .enable = mac_enable,
- .disable = mac_disable,
- .set_mtu = mac_set_mtu,
- .set_rx_mode = mac_set_rx_mode,
- .set_speed_duplex_fc = mac_set_speed_duplex_fc,
- .macaddress_get = mac_get_address,
- .statistics_update = mac_update_statistics,
-};
-
-static struct cmac *mac_create(adapter_t *adapter, int index)
-{
- struct cmac *mac;
- u32 data32;
-
- if (index >= 4)
- return NULL;
-
- mac = kzalloc(sizeof(*mac) + sizeof(cmac_instance), GFP_KERNEL);
- if (!mac)
- return NULL;
-
- mac->ops = &chelsio_mac_ops;
- mac->instance = (cmac_instance *) (mac + 1);
-
- mac->instance->index = index;
- mac->adapter = adapter;
-
- data32 = readl(adapter->regs + MAC_REG_CSR(mac->instance->index));
- data32 &= ~(F_MAC_RESET | F_MAC_PROMISC | F_MAC_PROMISC |
- F_MAC_LB_ENABLE | F_MAC_RX_ENABLE | F_MAC_TX_ENABLE);
- data32 |= F_MAC_JUMBO_ENABLE;
- writel(data32, adapter->regs + MAC_REG_CSR(mac->instance->index));
-
- /* Initialize the random backoff seed. */
- data32 = 0x55aa + (3 * index);
- writel(data32,
- adapter->regs + MAC_REG_GMRANDBACKOFFSEED(mac->instance->index));
-
- /* Check to see if the mac address needs to be set manually. */
- data32 = readl(adapter->regs + MAC_REG_IDLO(mac->instance->index));
- if (data32 == 0 || data32 == 0xffffffff) {
- /*
- * Add a default MAC address if we can't read one.
- */
- writel(0x43FFFFFF - index,
- adapter->regs + MAC_REG_IDLO(mac->instance->index));
- writel(0x0007,
- adapter->regs + MAC_REG_IDHI(mac->instance->index));
- }
-
- (void) mac_set_mtu(mac, 1500);
- return mac;
-}
-
-const struct gmac t1_chelsio_mac_ops = {
- .create = mac_create
-};
--- a/drivers/net/chelsio/subr.c 2007-10-08 16:04:04.000000000 -0700
+++ b/drivers/net/chelsio/subr.c 2007-10-08 16:08:10.000000000 -0700
@@ -884,7 +884,7 @@ static int asic_slow_intr(adapter_t *ada
if (cause & F_PL_INTR_PCIX)
t1_pci_intr_handler(adapter);
if (cause & F_PL_INTR_EXT)
- t1_elmer0_ext_intr_handler(adapter);
+ t1_elmer0_ext_intr(adapter);
/* Clear the interrupts just processed. */
writel(cause, adapter->regs + A_PL_CAUSE);
^ 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