ensuring no re-ordering and a "fast" classifier are
gone.
I am almost tempted to say go back and write a qdisc called FQ.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2007-30-05 at 17:27 +0200, Patrick McHardy wrote:
> jamal wrote:
> Sure. The thing I don't like about the predefined hash functions is
> that its unflexible.
>
agreed.
> > skb->prio as a selector. I think if you removed that it should be fine.
>
> I
FQ and have a new qdisc.
The "removed" hashing dynamic classifier would of course be better off
it allowed the user to select a hash algorithm such as the other ones
specified in ESFQ.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the b
call.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
see if i am missing something we agreed on.
Herbert, I cant see any easier way to do the SAD lookup. If you have
suggestions please shoot. I am shooting for this to go in when 2.6.23
opens up.
cheers,
jamal
commit 707411e190af516cefdc3315183d023fde54d53e
Author: Jamal Hadi Salim <[EM
W, the fact select() doesnt kick at all (been a while since i last
tried) is something that seems to be a bug.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
i have no other choice.
BTW, wheres the e1000 change?
cheers,
jamal
[1] If for example you wrote a classifier or a qdisc (as in a recent
discussion I had with Patrick) i would say it is your code and your
effort and i have the choice not to use it (by virtue of there being
other alternatives). I have
hernet type for IPV4.
> Hope that helps someone clue me in as to which network part is reusing
> the data. Do I need to 'pin' the sk_buff until the pipe data has been
> consumed?
I would worry about the driver level first - likely thats where your
corruption is.
cheers,
jamal
E and
ifi_type ifinfomsg.
But i cant come with a better noun.
Good stuff, nevertheless
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
r not use the multiqueue
> codepath. Can you please explain what your real issue is here?
There will be no issue if a) multiple APIs would be allowed for driver
multi-rings[1] and b) you didnt touch the qdiscs.
Given that #a is not a sensible thing to do since there can only be one
API and
;-> Thanks.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
beats me)
to get tg3 working. It would be nice if someone converted some 10G
ethernet driver.
cheers,
jamal
pktgen.batch-1-1
Description: application/shellscript
. I am working on a couple of
things (batching and recovering pktgen ipsec patches)- I will work on
those patches soon after.
Iam actually not against the subqueue control - i know Peter needs it
for certain hardware; i am just against the mucking around of the common
case (single ring NIC) ju
On Wed, 2007-06-06 at 15:35 -0700, David Miller wrote:
> From: jamal <[EMAIL PROTECTED]>
> Date: Wed, 06 Jun 2007 18:13:40 -0400
> There are other reasons to do interesting things in this area,
> purely for parallelization reasons.
>
> For example, consider a chip that h
us, and we have to
>design for this.
>
There is no potential for parallelizing on transmit that i can think of.
Dave, please explain it slowly so i can understand it.
There is huge potential for parallelizing on receive. But i am certainly
missing the value in the transmit.
cheers,
jamal
-
path once a packet is received, that is a CPU problem
(and therefore multi CPUs help).
To be fair to Peter, that is not what his patches are trying to address
(and infact, they cant solve that problem).
off for the night.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscrib
ll
extension to the batching patches will provide the change i am
proposing.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
erf requires end 2 end semantics).
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
be easy to find.
When i turned off the _BTX changes i saw no difference with pktgen.
But that is a different code path.
> Summary : Average BW (whatever meaning that has) improved 0.65%, while
> Service Demand deteriorated 11.86%
Sorry, been many moons since i last played w
On Wed, 2007-06-06 at 21:08 -0400, jamal wrote:
> It's too depressing - so i came back here for a break ;->
I am sure you would agree it was too depressing ;->
> As a side note: You will have to do a lot of surgery to the current code
> to make tx run on multi CPUs. It need
000 ;->
I think the e1000s challenges are related to the gazillion variations of
boards they support and a little challenge of too many intel cooks.
Auke, why do you need the tx ring lock?
cheers,
jamal
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index 16a6edf..4483d0f
stly useless.
And like i said I have done a quick test with an SMP machine and it
seems to work fine; but your tests will probably be more thorough.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
hink just a 5
tuple classification would be sufficient.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
OK))
> return NETDEV_TX_OK;
>
Dont wanna change the way e1000 behaves. It returns NETDEV_TX_OK even
when it netif_stops; this allows the top layer to exit.
> P.S. I do not have e1000 hardware to test, the only testing machine has
> r8169 driver.
Send me your shi
ion
between tx and rx?
> You'll need bidirectional traffic with multiple clients probably to hit it...
I did - but it was asymettric i.e very heavy on tx.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECT
On Wed, 2007-06-06 at 09:49 -0400, jamal wrote:
> If you help out, when you post your results, can you please say what
> hardware and setup was?
Ok, i have tested on new hardware with pktgen:
Machine: Dual Xeon processor with EMT64 - kernel is 32 bit.
Chipset: E7520 Memory Controller Hu
On Thu, 2007-07-06 at 15:44 -0700, David Miller wrote:
> From: jamal <[EMAIL PROTECTED]>
> Date: Thu, 07 Jun 2007 17:57:25 -0400
>
> > I empathize but take a closer look; seems mostly useless.
>
> I thought E1000 still uses LLTX, and if so then multiple cpus can mos
ach other simply by tp->tx_lock because tp->tx_lock only
runs on CPU0.
Is it a bug then?
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2007-07-06 at 16:00 -0700, David Miller wrote:
> That's right we fixed that the other week.
Circa 2.6.18 to be exact - Hence "In Pursuit of Herbert Xu" ;->
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body o
n if you got rid of LLTX that netif_tx_lock is unnecessary.
Herbert?
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
perf provides it as us/KB. I don't know the internals of
> netperf enough to say how this is calculated.
I am hoping Rick would comment.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> I am running a larger 5 iteration run with buffer sizes :8,32,128,512,1
> K,4K,16K.
> It is going to run for around 12 hours and since I am moving house during
> the
> weekend, I will be able to look at the results only on Monday.
>
sounds good.
cheers,
jamal
-
To unsubscri
On Fri, 2007-08-06 at 12:38 +0400, Evgeniy Polyakov wrote:
> On Thu, Jun 07, 2007 at 06:23:16PM -0400, jamal ([EMAIL PROTECTED]) wrote:
> > I believe both are called with no lock. The idea is to avoid the lock
> > entirely when unneeded. That code may end up finding
k will
certainly bring down the performance numbers on a send/recv profile.
The bizare thing is things run just fine even under the heavy tx/rx
traffic i was testing under. I guess i didnt hit hard enough.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the b
on the tx side and using the rx side
concurently.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2007-08-06 at 16:09 +0400, Evgeniy Polyakov wrote:
> On Fri, Jun 08, 2007 at 07:31:07AM -0400, jamal ([EMAIL PROTECTED]) wrote:
> But lock is still being hold - or there was no intention to reduce lock
> usage? As far as I read Krishna's mail, lock usage was not an issue,
ond and divide
> to get microseconds per KB for the aggregate.
>From what you are saying above seems to me that for more than one proc
it is safe to just run netperf4 instead of netperf2?
It also seems reasonable to set up large socket buffers on the receiver.
cheers,
jamal
-
To unsubscribe
; pushed down into the individual tx_ring struct, not at the adapter
> level.
That sounds right - but the adapter lock is not related to tx_lock in
current e1000, correct?
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
time!].
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
1 of 4.
cheers,
jamal
commit f7da845f37e3cd47be46697491210c126b37c8fc
Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
Date: Sat Jun 9 09:11:16 2007 -0400
[PKTGEN] Centralize packet overhead tracking
Track the extra packet overhead for VLAN tags, MPLS, IPSEC etc
Signed-
2 of 4.
cheers,
jamal
commit d0d2c0c2e5539a54d66f07d2fa99bb52c19cc698
Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
Date: Sat Jun 9 09:12:21 2007 -0400
[PKTGEN] Introduce sequential flows
By default all flows in pktgen are randomly selected.
This patch introduces abil
3 of 4.
cheers,
jamal
commit 923d6c49f9f513da41e4bfd8188304787a5c8093
Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
Date: Sat Jun 9 09:16:12 2007 -0400
[XFRM] Introduce standalone SAD lookup
This allows other in-kernel functions to do SAD lookups.
The only known user at the
4 of 4
cheers,
jamal
commit d1d8ea490a517df484e6774c4f41123ccde52434
Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
Date: Sat Jun 9 09:46:52 2007 -0400
[PKTGEN] IPSEC support
Added transport mode ESP support for starters.
I will send more of these modes and types once i have re
Sorry, meant to cc Herbert and James since they commented two
generations ago.
Gents, if you manage to have the cycles please look at this specific
one. Herbert, for tunnel mode i think i will agree with you and
introduce a dst struct; but i will defer that to some later patch.
cheers,
jamal
On
nature of the NAPI
poll only one CPU can prune the descriptors.
I have tested with just getting rid of tx_lock and it worked fine. I
havent tried removing the adapter lock.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message t
ltiqueue HW is here and other stacks already taking
> advantage of it.
My main contention with the Peters approach has been to do with the
propagating of flow control back to the qdisc queues. However, if this
PCI SIG standard is also desiring such an approach then it will shed a
different light.
ch
>
> One solution could be to provide a generic API for QoS level to a
> channel
> (and also to a generic NIC!).
> Internally, device driver can translate QoS requirements into flow
> control, pci bus bandwidth, and whatever else is shared on the physical
> NIC between the c
n 0 always wins over 1 which wins over 2.
Same thing if you queue into hardware and the priorization is the same.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2007-11-06 at 14:39 +0200, Patrick McHardy wrote:
> jamal wrote:
> > On Mon, 2007-11-06 at 13:58 +0200, Patrick McHardy wrote:
> >
> > Sure. Packets stashed on the any DMA ring are considered "gone to the
> > wire". That is a very valid assump
On Mon, 2007-11-06 at 15:03 +0200, Patrick McHardy wrote:
> jamal wrote:
> Well, its not.
I dont wanna go into those old style debates again; so lets drop this
point.
> > Take a step back:
> > When you put a packet on the DMA ring, are you ever going to take it
> > away
questions, changing a driver and wide
testing. I may target tg3 next and write a tool to do testing from
UDP level.
cheers,
jamal
Heres the begining of a howto for driver author.
The current working tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/hadi/batch-lin26.git
The intended
On Mon, 2007-11-06 at 16:03 +0200, Patrick McHardy wrote:
> jamal wrote:
> > Sure - but what is wrong with that?
>
> Nothing, this was just to illustrate why I disagree with the assumption
> that the packet has hit the wire.
fair enough.
> On second thought I do agree w
t the high prio packets; however, it is feasible that high prio
packets will obstruct low prio packets (which is fine).
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
gher prio packet makes it out.
> With multiple queue states we'd know that
> queue 0 can still take packets.
And with what i described you dont make any such changes to the core;
the burden is on the driver.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2007-11-06 at 18:00 +0300, Tomas Winkler wrote:
> On 6/11/07, jamal <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-11-06 at 17:30 +0300, Cohen, Guy wrote:
> >
> > >
> > > For WiFi devices the HW often implements the scheduling, especially when
> >
t or prun tx descriptors, if a ring <= X has
transmitted a packet (or threshold of packets), then wake up the driver
(i.e open up).
In the meantime packets from the stack are sitting on the qdisc and will
be sent when the driver opens up.
Anyways, I have to run to work; thanks for keeping the di
On Mon, 2007-11-06 at 17:44 +0200, Patrick McHardy wrote:
> jamal wrote:
[..]
> > - let the driver shutdown whenever a ring is full. Remember which ring X
> > shut it down.
> > - when you get a tx interupt or prun tx descriptors, if a ring <= X has
> > transmitted a p
On Mon, 2007-11-06 at 18:34 +0300, Cohen, Guy wrote:
> jamal wrote:
[..]
> > WMM is a strict prio mechanism.
> > The parametrization very much favors the high prio packets when the
> > tx opportunity to send shows up.
>
> Sorry, but this not as simple as you de
A small update on the e1000
On Mon, 2007-11-06 at 09:52 -0400, jamal wrote:
> I have started writting a small howto for drivers. Hoping to get a wider
> testing with more drivers.
> So far i have changed e1000 and tun drivers as well as modified the
> packetgen tool to do batc
Sorry - i was distracted elsewhere and didnt respond to your
earlier email; this one seems a superset.
On Tue, 2007-12-06 at 02:58 +0200, Patrick McHardy wrote:
> jamal wrote:
> > On Mon, 2007-11-06 at 17:44 +0200, Patrick McHardy wrote:
[use case abbreviated..]
the use case is sensibl
these to net-2.6.23 as soon as Robert Acks
them.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Manual labor still ... 1 of 4
cheers,
jamal
commit 38477d7ddfa58f58cce99bc902b4c18883647a71
Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
Date: Tue Jun 12 06:43:00 2007 -0400
[PKTGEN] Centralize packet overhead tracking
Track the extra packet overhead for VLAN tags, MPLS, IPS
2 of 4
cheers,
jamal
commit 882c296bb3f153e1ac770a874c75cfb2bab8481b
Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
Date: Tue Jun 12 07:24:00 2007 -0400
[PKTGEN] Introduce sequential flows
By default all flows in pktgen are randomly selected.
This patch introduces abil
3 of 4 ..
cheers,
jamal
commit 677f1c1459218919f5aa2622625dc8709c2a98ce
Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
Date: Tue Jun 12 07:28:59 2007 -0400
[XFRM] Introduce standalone SAD lookup
This allows other in-kernel functions to do SAD lookups.
The only known user
4 of 4
cheers,
jamal
commit e035613eae587251b8c98b7d503eab207f1d26e2
Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
Date: Tue Jun 12 07:43:30 2007 -0400
[PKTGEN] IPSEC support
Added transport mode ESP support for starters.
I will send more of these modes and types once
On Tue, 2007-12-06 at 11:19 +0200, Johannes Berg wrote:
> On Mon, 2007-06-11 at 08:23 -0400, jamal wrote:
> > Sure. Packets stashed on the any DMA ring are considered "gone to the
> > wire". That is a very valid assumption to make.
>
> Not at all! Packets could
On Tue, 2007-12-06 at 15:21 +0200, Patrick McHardy wrote:
> jamal wrote:
>
>
> Yes. Using a higher threshold reduces the overhead, but leads to
> lower priority packets getting out even if higher priority packets
> are present in the qdisc.
As per earlier discussion, the pac
On Tue, 2007-12-06 at 15:21 +0200, Robert Olsson wrote:
>
>I'll guess the ipsec part is to be considered work-in-progress
>and you're doing both the work and the progress.
>
;->
Much thanks Robert.
cheers,
jamal
-
To unsubscribe from this list: s
ant to keep the first condition similar to xfrm_state_find
> (but the mode and proto conditions are reversed anyways).
>
Will do.
> BTW, wouldn't it make sense to allow use of the SPI as well?
SPI is the least user friendly parameter - but i could add it later.
I want to add tunn
Guy,
I apologize for not responding immediately - i promise to in a few hours
when i get back (and read it over some good coffee) - seems like you
have some good stuff there; thanks for taking the time despite the
overload.
cheers,
jamal
On Tue, 2007-12-06 at 17:04 +0300, Cohen, Guy wrote:
>
This takes into considerations Patricks feedback.
cheers,
jamal
commit 4fe3190756589ef8155eb97fe725f2564f1fc77d
Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
Date: Tue Jun 12 12:35:39 2007 -0400
[XFRM] Introduce standalone SAD lookup
This allows other in-kernel functions to
Sorry Robert, I found a problem compiling when i turned off XFRM. This
fixes it.
cheers,
jamal
commit bfd389bba7654aa118f0949ff0de45a3bce9700c
Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
Date: Tue Jun 12 18:59:33 2007 -0400
[PKTGEN] IPSEC support
Added transport mode ESP suppo
Hi Guy,
On Tue, 2007-12-06 at 17:04 +0300, Cohen, Guy wrote:
> Hi Jamal,
>
> Here is a simple scenario (nothing here is rare of extreme case):
> - Busy wireless environment
> - FTP TX on BE queue (low priority)
> - Skype TX on VO queue (high priority)
>
> The channel is
nalling which is usable. Guy Cohen gave a good use case
which i responded to. Do you wanna look at that and respond?
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ter name) it may be harder to do
parallelization on rcv if you use what i said above. But you could
use a different model on receive - such as create a single netdev and
with 8 rcv rings and MSI tied on rcv to 8 different CPUs
Anyways, it is an important discussion to have. ttl.
cheers,
jamal
On Wed, 2007-13-06 at 11:20 -0700, David Miller wrote:
> From: jamal <[EMAIL PROTECTED]>
> Date: Wed, 13 Jun 2007 09:33:22 -0400
>
> > So in such a case (assuming 8 rings), One model is creating 4 netdev
> > devices each based on single tx/rx ring and register set a
On Thu, 2007-14-06 at 16:59 +0800, Zhang Rui wrote:
> Hi, Jamal,
>
> Now the genl utility can find the acpi event genetlink family.
> And a simple user space demo is finished for handling acpi event.
> I really appreciate your help. :)
np.
> I think the patch which expos
Hi Yi,
On Thu, 2007-14-06 at 10:44 +0800, Zhu Yi wrote:
> On Wed, 2007-06-13 at 08:32 -0400, jamal wrote:
> > The key arguement i make (from day one actually) is to leave the
> > majority of the work to the driver.
>
> But it seems not feasible the Qdisc needs to k
at's why I said that this demo receives all the broadcasted genetlink
> messages.
Ok, tell me how to generate these ACPI events and i will patch my laptop
and test it. What kernel compile options do i need? 2.6.24-rc4 will do?
cheers,
jamal
-
To unsubscribe from this list: send the line &
agement frames (actually DCE does) to help.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
time) - your kernel code
is sending to group 1; i.e
genlmsg_multicast(skb, 0, 1, GFP_ATOMIC);
you need to change that to send to your assigned id, i.e:
genlmsg_multicast(skb, 0, acpi_event_genl_family.id, GFP_ATOMIC);
then the user space code will work. I should be able to look at it if it
doesn
epeat the same arguements over and over again. It is
ok for rational people to agree to disagree for the sake of progress
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
hread is going back and forth on the same recycled
arguements. As an example, i have responded to this specific question.
Can we drop the discussion?
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordom
On Mon, 2007-18-06 at 20:58 -0700, David Miller wrote:
> From: Krishna Kumar2 <[EMAIL PROTECTED]>
> Date: Tue, 19 Jun 2007 09:05:28 +0530
>
> > Dave, does it make sense to add this to 2.6.23 ? Herbert and Peter
> > had earlier reviewed Patch 2/2 and said they were OK wi
oup per entity. Most users only need that
one.
If you need more, we go one of two ways:
a) Register for multiple IDs with the code as is.
b) we could add a "reserve multicast group" interface in the kernel.
Thoughts?
cheers,
jamal
-
To unsubscribe from this list: send the line "un
ful to sort of measure CPU utilization
as well (my understanding is netperf4 is more capable of that).
I think the benefit would be a lot more visible as the number of flows
goes up (simply because there will be a lot more packets/sec going into
the driver).
cheers,
jamal
-
To unsubscribe from this li
RS is not set
I will try to turn on those in a few days and see if notice a
difference.
Again, thanks Evgeniy.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
tch - which
should give you decent numbers. Lets see how Robert responds and if you
have time, turn off the kernel configs like i did.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
source
[EMAIL PROTECTED]:~$ sudo
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet
---
cheers,
jamal
PS:- i wont be able to respond for another 24 hrs or so.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a m
On Tue, 2007-19-06 at 16:25 -0700, Stephen Hemminger wrote:
> Using current xfrm.h from kernel headers, causes conflicts.
> Instead of XFRMA_SADCNT, it should be using XFRMA_SAD_CNT.
>
Yeah, that changed in the kernel header.
If it compiles, it should be fine; thanks Stephen.
chee
k.
> but your point is invalid. The
> Qdisc must be changed to have the hardware queue information to support
> multiple hardware queues devices.
>
Handwaving as above doesnt add value to a discussion. If you want
meaningful discussions, stop these cliches.
cheers,
jamal
-
To unsubscribe fr
etlink will want at least one...
>
The multicast issue wasnt well-attacked. We have a group magically
assigned to a user based on their allocated id. It should be feasible
to add an API to the kernel for registering for many groups and allow
user space to discover these groups before reg
roc/interupts?
cheers,
jamal
The test variables are:
--
1) A Intel Xeon[1] machine vs an AMD opteron[2].
2) A plain 2622-rc4 kernel vs a 2622-rc4 with batching
(from git://git.kernel.org/pub/scm/linux/kernel/git/hadi/batch-lin26.git)
3) Different clock sources acpi-pm, jiffies and
On Thu, 2007-21-06 at 11:54 -0400, jamal wrote:
> The summary is: Batching always is better, jiffies is always the better
> clock source (and who would have thunk,eh? Opteron kicks a Xeons ass).
The results in the table for opteron and xeon are swapped when
cutnpasting from a larger test
On Fri, 2007-22-06 at 09:26 +0800, Zhu Yi wrote:
> On Thu, 2007-06-21 at 11:39 -0400, jamal wrote:
> It sounds stupid I'm still trying to convince you why we need multiqueue
> support in Qdisc when everybody else are already working on the code,
If you go back historically (maybe
On Thu, 2007-21-06 at 20:45 +0400, Evgeniy Polyakov wrote:
> On Thu, Jun 21, 2007 at 11:54:17AM -0400, jamal ([EMAIL PROTECTED]) wrote:
> > Evgeniy, did you sync on the batching case with the git tree?
>
> My tree contains following commits:
>
> L
On Thu, 2007-21-06 at 12:55 -0400, Benjamin LaHaise wrote:
> You should qualify that as 'Old P4 Xeon', as the Core 2 Xeons are leagues
> better.
The Xeon hardware is not that old - about a year or so (and so is the
opteron).
BTW, how could you tell this was old Xeon?
chee
could be done if
you register for multi groups.
cheers,
jamal
PS:- I just noticed Thomas wasnt CCed.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
e the hardware, what says
you? ;->
AFAIT, the main reason Opterons has the numbers it does is due to
the integrated on chip MC. I dont see Intel any time soon getting rid of
that (for economical reasons more than technical).
In any case i see batching as actually being a lot more cache friendly
nk ethtool is the way to go - I will update the batch tree with
that fix for e1000.
Back to the question: Do you recall how this number was arrived at?
128 packets will be sent out at GiGe in about 80 microsecs, so from a
feel-the-wind-direction perspective it seems reasonable.
cheers,
jamal
-
1 - 100 of 2312 matches
Mail list logo
