Hi Divy,
But the race doesn't exist even for LLTX drivers these days. There is no
way two cpu's can execute the xmit handler at the same time.
Thanks,
- KK
> > > > The first part of the patch removes the !netif_queue_stopped(dev).
> > > > It opens the race discussed a while ago between Stephen
Hi Divy,
> > Explain why, so I can include it in the changelog please...
>
> Hi Jeff,
>
> The first part of the patch removes the !netif_queue_stopped(dev).
> It opens the race discussed a while ago between Stephen hemminger and
> David Miller:
> http://marc.info/?l=linux-netdev&m=113383224512427&
I forgot to mention but the patch is only compile tested as I don't have
hardware to test it.
Krishna Kumar2/India/[EMAIL PROTECTED] wrote on 01/30/2008 12:30:16 PM:
> Changes:
>1. Add common code for stopping queue.
>2. No need to call netif_stop_queue followed by netif_w
of who was seeing it due to large number of reports :-), could
> somebody refresh my memory because I currently don't have time to dig it
> up from archives (at least on this week).
>
>
> --
> i.
>
> --
> [PATCH] [TCP]: NewReno must count every skb while marking l
[EMAIL PROTECTED] wrote on 01/23/2008 03:23:24 PM:
> > There were couple of patch apply failures in .c files which I fixed by
> > hand.
> > But when compiling, I got these errors (I am using DM's 2.6.24-rc7
kernel,
> > net-2.6.25.git):
>
> Well, that's annoying, you didn't mention net-2.6.25 back
David Miller <[EMAIL PROTECTED]> wrote on 01/23/2008 01:27:23 PM:
> > iperf with multiple threads almost always gets these 4, *especially*
when I
> > do some batching :).
> >
> > static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int
flag)
> > {
> > ...
> > if (WARN_ON(
Sorry for the duplicate bug report, I just saw that Dave Young had already
reported three of the
4 assertions that I was getting. The only different assert I am getting is:
iperf with multiple threads almost always gets these 4, *especially* when I
do some batching :).
static void tcp_fastretrans
Hi all,
While running some simple iperf tests (multi-threaded using either E1000 or
IPoIB), I
started getting these two assertions starting about 3 weeks back (though it
could be
older to that since my earlier bits were not upto date). Bits are
unmodified 2.6.24-rc7
bits downloaded today (Jan 23r
Hi Auke,
"Kok, Auke" <[EMAIL PROTECTED]> wrote on 11/14/2007 02:58:14 AM:
> this doesn't apply anymore and it would help if you could re-spin this
for e1000e.
> I don't know what the status for merging of the batched xmit patches is
right now
> but it would help if you could rewrite them against
> > You could optimize this by getting HARD_TX_LOCK after the check. I
> > assume that netif_stop_subqueue (from another CPU) would always be
> > called by the driver xmit, and that is not possible since we hold
> > the __LINK_STATE_QDISC_RUNNING bit. Does that sound correct?
>
> I don't think this
Hi Dave,
David Miller <[EMAIL PROTECTED]> wrote on 11/14/2007 11:44:39 AM:
> > You could optimize this by getting HARD_TX_LOCK after the check. I
> > assume that netif_stop_subqueue (from another CPU) would always be
> > called by the driver xmit, and that is not possible since we hold
> > the __
Hi Yoshifuji,
YOSHIFUJI Hideaki wrote on 10/30/2007 11:22:37 AM:
> -static inline int ipv6_saddr_label(const struct in6_addr *addr, int
type)
> +static inline int ipv6_addr_label(const struct in6_addr *addr, int type,
> +int ifindex)
This function
Gui Jianfeng wrote on 10/22/2007 11:37:07 AM:
> @@ -310,8 +310,12 @@ static inline int ip_rcv_finish(struct s
> * how the packet travels inside Linux networking.
> */
> if (skb->dst == NULL) {
> - if (ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev))
> - goto
Hi Dave,
David Miller wrote on 10/10/2007 02:13:31 AM:
> > Hopefully that new qdisc will just use the TX rings of the hardware
> > directly. They are typically large enough these days. That might avoid
> > some locking in this critical path.
>
> Indeed, I also realized last night that for the def
Hi Dave,
David Miller <[EMAIL PROTECTED]> wrote on 10/09/2007 04:32:55 PM:
> > Isn't it enough that the multiqueue+batching drivers handle skbs
> > belonging to different queue's themselves, instead of qdisc having
> > to figure that out? This will reduce costs for most skbs that are
> > neither
David Miller <[EMAIL PROTECTED]> wrote on 10/09/2007 04:32:55 PM:
> Ignore LLTX, it sucks, it was a big mistake, and we will get rid of
> it.
Great, this will make life easy. Any idea how long that would take?
It seems simple enough to do.
thanks,
- KK
-
To unsubscribe from this list: send the
Hi Peter,
"Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]> wrote on
10/09/2007 04:03:42 AM:
> > true, that needs some resolution. Heres a hand-waving thought:
> > Assuming all packets of a specific map end up in the same
> > qdiscn queue, it seems feasible to ask the qdisc scheduler to
> > give us en
J Hadi Salim <[EMAIL PROTECTED]> wrote on 10/08/2007 07:35:20 PM:
> I dont see something from Krishna's approach that i can take and reuse.
> This maybe because my old approaches have evolved from the same path.
> There is a long list but as a sample: i used to do a lot more work while
> holding t
J Hadi Salim <[EMAIL PROTECTED]> wrote on 10/08/2007 06:47:24 PM:
> two, there should _never_ be any requeueing even if LLTX in the previous
> patches when i supported them; if there is, it is a bug. This is because
> we dont send more than what the driver asked for via xmit_win. So if it
> asked
12:06:23 AM:
> This patch introduces the netdevice interface for batching.
>
> cheers,
> jamal
>
>
> [attachment "oct07-p1of3" deleted by Krishna Kumar2/India/IBM]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a messa
> jamal wrote:
>
> > > + while ((skb = __skb_dequeue(skbs)) != NULL)
> > > + q->ops->requeue(skb, q);
> >
> >
> > ->requeue queues at the head, so this looks like it would reverse
> > the order of the skbs.
>
> Excellent catch! thanks; i will fix.
>
> As a side note: Any batching driver sho
Varun Chandramohan <[EMAIL PROTECTED]> wrote on 09/20/2007 08:59:03
PM:
> @@ -2123,6 +2131,7 @@ static int rt6_fill_node(struct sk_buff
> {
> struct rtmsg *rtm;
> struct nlmsghdr *nlh;
> + struct timeval tv;
> long expires;
> u32 table;
>
> @@ -2186,6 +2195,11 @@ static int rt6_
PROTECTED]> wrote on 09/20/2007 10:42:24 AM:
> From: Krishna Kumar2 <[EMAIL PROTECTED]>
> Date: Thu, 20 Sep 2007 10:40:33 +0530
>
> > I like the clean changes made by Dave to fix this, and will test it
> > today (if I can get my crashed system to come up).
>
> I wo
Hi Dave,
David Miller <[EMAIL PROTECTED]> wrote on 09/19/2007 09:35:57 PM:
> The NAPI_STATE_SCHED flag bit should provide all of the necessary
> synchornization.
>
> Only the setter of that bit should add the NAPI instance to the
> polling list.
>
> The polling loop runs atomically on the cpu whe
Hi Jan-Bernd,
Jan-Bernd Themann <[EMAIL PROTECTED]> wrote on 09/19/2007 06:53:48 PM:
> If I understood it right the problem you describe (quota update in
> __napi_schdule) can cause further problems when you choose the
> following numbers:
>
> CPU1: A. process 99 pkts
> CPU1: B. netif_rx_complete
Hi Roland,
> Please double check your tree. I just very carefully looked at my
> trees, and the poll_more: label is added in commit 6b460a71 ("[NET]:
> Make NAPI polling independent of struct net_device objects.") which is
> only in the net-2.6.24 tree. Of course Dave did not change the
> versio
Hi Roland,
Roland Dreier <[EMAIL PROTECTED]> wrote on 09/18/2007 07:57:24 PM:
> > While using IPoIB over EHCA (rc6 bits), unregister_netdev hangs with
>
> I don't think you're actually using rc6 bits, since in your patch you
have:
>
> > -poll_more:
>
> and I think that is only in Dave's net-2.6
[Removing Jeff as requested from thread :) ]
Hi Dave,
David Miller <[EMAIL PROTECTED]> wrote on 09/17/2007 07:55:02 AM:
> From: jamal <[EMAIL PROTECTED]>
> Date: Sun, 16 Sep 2007 22:14:21 -0400
>
> > I still think this work - despite my vested interest - needs more
> > scrutiny from a performanc
Hi Randy,
Randy Dunlap <[EMAIL PROTECTED]> wrote on 09/15/2007 12:07:09 AM:
> > + To fix this problem, error cases where driver xmit gets called with
a
> > + skb must code as follows:
> > + 1. If driver xmit cannot get tx lock, return NETDEV_TX_LOCKED
> > + as usual. This allows
Hi Dave,
David Miller <[EMAIL PROTECTED]> wrote on 09/17/2007 04:47:48 AM:
> The only major complaint I have about this patch series is that
> the IPoIB part should just be one big changeset. Otherwise the
> tree is not bisectable, for example the initial ipoib header file
> change breaks the bu
Hi Evgeniy,
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 09/14/2007 06:17:14 PM:
> > if (unlikely(skb->len <= 0)) {
> >dev_kfree_skb_any(skb);
> > - return NETDEV_TX_OK;
> > + return NETDEV_TX_DROPPED;
> > }
>
> This changes could actually go as own patch, although not
Hi Evgeniy,
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 09/14/2007 06:16:38 PM:
> > + if (dev->features & NETIF_F_BATCH_SKBS) {
> > + /* Driver supports batching skb */
> > + dev->skb_blist = kmalloc(sizeof *dev->skb_blist, GFP_KERNEL);
> > + if (dev->skb_blist)
> > + s
Hi Evgeniy,
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 09/14/2007 05:45:19 PM:
> > + if (skb->next) {
> > + int count = 0;
> > +
> > + do {
> > +struct sk_buff *nskb = skb->next;
> > +
> > +skb->next = nskb->next;
> > +__skb_queue_tail(d
te on 08/29/2007 10:21:50 AM:
> From: Krishna Kumar2 <[EMAIL PROTECTED]>
> Date: Wed, 29 Aug 2007 08:53:30 +0530
>
> > I am scp'ng from 192.168.1.1 to 192.168.1.2 and captured at the send
> > side.
>
> Bad choice of test, this is cpu limited since the scp
&g
Eric W. Biederman wrote on 09/09/2007 02:45:34 AM:
Hi Eric,
> +static int register_pernet_operations(struct list_head *list,
> + struct pernet_operations *ops)
> +{
>
> +out:
> + return error;
> +
> +out_undo:
> + /* If I have an error cleanup all namespaces I initialized */
Some init handlers set iflink, and hence it is required. See tunnel init
routines (ipip_tunnel_init), macvlan_init(), etc
[EMAIL PROTECTED] wrote on 09/06/2007 10:57:24 AM:
> - minor logic cleanup
>
> Signed-off-by: Wang Chen <[EMAIL PROTECTED]>
>
> diff -Nurp linux-2.6.22.4.org/net/core/dev.c l
Hi Dave,
David Miller <[EMAIL PROTECTED]> wrote on 08/29/2007 10:21:50 AM:
> From: Krishna Kumar2 <[EMAIL PROTECTED]>
> Date: Wed, 29 Aug 2007 08:53:30 +0530
>
> > I am scp'ng from 192.168.1.1 to 192.168.1.2 and captured at the send
> > side.
>
> Bad c
Hi Rick,
> > From: Rick Jones <[EMAIL PROTECTED]>
> >>The trace I've been sent shows clean RTTs ranging from ~200
milliseconds
> >>to ~7000 milliseconds.
> >
> >
> > Thanks for the info.
> >
> > It's pretty easy to generate examples where we might have some sockets
> > talking over interfaces on s
[EMAIL PROTECTED] wrote on 08/29/2007 10:21:50 AM:
> From: Krishna Kumar2 <[EMAIL PROTECTED]>
> Date: Wed, 29 Aug 2007 08:53:30 +0530
>
> > I am scp'ng from 192.168.1.1 to 192.168.1.2 and captured at the send
> > side.
>
> Bad choice of test, this is cpu limi
2 114777 -.13
I will run netperf and report CPU utilization too.
Thanks,
- KK
David Miller <[EMAIL PROTECTED]> wrote on 08/21/2007 12:48:24 PM:
> From: Krishna Kumar2 <[EMAIL PROTECTED]>
> Date: Fri, 17 Aug 2007 11:36:03 +0530
>
> > > I ran 3
Hi Randy,
Thanks for your suggestions. Will clean up those changes.
- KK
Randy Dunlap <[EMAIL PROTECTED]> wrote on 08/22/2007 09:20:13 PM:
> On Wed, 22 Aug 2007 13:58:58 +0530 Krishna Kumar wrote:
>
> > Add Documentation describing batching skb xmit capability.
> >
> > Signed-off-by: Krishna Ku
Hi Auke,
"Kok, Auke" <[EMAIL PROTECTED]> wrote on 08/22/2007 08:09:31 PM:
> Krishna,
>
> while I appreciate the patch I would have preferred a patch to e1000e.
Not only
> does the e1000e driver remove a lot of the workarounds for old silicon,
it is
> also a good way for us to move the current e10
David Miller <[EMAIL PROTECTED]> wrote on 08/22/2007 02:44:40 PM:
> From: Krishna Kumar2 <[EMAIL PROTECTED]>
> Date: Wed, 22 Aug 2007 12:33:04 +0530
>
> > Does turning off batching solve that problem? What I mean by that is:
> > batching can be disabled if a T
Hi Dave,
David Miller <[EMAIL PROTECTED]> wrote on 08/22/2007 09:52:29 AM:
> From: Krishna Kumar2 <[EMAIL PROTECTED]>
> Date: Wed, 22 Aug 2007 09:41:52 +0530
>
> > > Because TSO does batching already, so it's a very good
> > > "tit for tat&qu
David Miller <[EMAIL PROTECTED]> wrote on 08/22/2007 12:21:43 AM:
> From: jamal <[EMAIL PROTECTED]>
> Date: Tue, 21 Aug 2007 08:30:22 -0400
>
> > On Tue, 2007-21-08 at 00:18 -0700, David Miller wrote:
> >
> > > Using 16K buffer size really isn't going to keep the pipe full enough
> > > for TSO.
>
Hi Dave,
> I ran 3 iterations of 45 sec tests (total 1 hour 16 min, but I will
> run a longer one tonight). The results are (results in KB/s, and %):
I ran a 8.5 hours run with no batching + another 8.5 hours run with
batching (Buffer sizes: "32 128 512 4096 16384", Threads: "1 8 32",
Each test
Forgot to mention one thing:
> This fix reduced
> retransmissions from 180,000 to 55,000 or so. When I changed IPoIB
> driver to use iterative sends of each skb instead of creating multiple
> Work Request's, that number went down to 15].
This also reduced TCP No Delay performance from huge perce
Hi Dave,
David Miller <[EMAIL PROTECTED]> wrote on 08/08/2007 04:19:00 PM:
> From: Krishna Kumar <[EMAIL PROTECTED]>
> Date: Wed, 08 Aug 2007 15:01:14 +0530
>
> > RESULTS: The performance improvement for TCP No Delay is in the range
of -8%
> >to 320% (with -8% being the sole negative), with m
David Miller <[EMAIL PROTECTED]> wrote on 08/09/2007 09:57:27 AM:
>
> > Patrick had suggested calling dev_hard_start_xmit() instead of
> > conditionally calling the new API and to remove the new API
> > entirely. The driver determines whether batching is required or
> > not depending on (skb==NULL)
Hi Dave,
David Miller <[EMAIL PROTECTED]> wrote on 08/09/2007 03:31:37 AM:
> > What do you generally think of the patch/implementation ? :)
>
> We have two driver implementation paths on recieve and now
> we'll have two on send, and that's not a good trend.
Correct.
> In an ideal world all the
Hi Patrick,
Patrick McHardy <[EMAIL PROTECTED]> wrote on 08/08/2007 07:35:17 PM:
> Krishna Kumar wrote:
> > +static inline int get_skb(struct net_device *dev, struct Qdisc *q,
> > + struct sk_buff_head *blist, struct sk_buff **skbp)
> > +{
> > + if (likely(!blist || (!skb_queue_len(b
Herbert Xu <[EMAIL PROTECTED]> wrote on 08/08/2007 07:12:47 PM:
> On Wed, Aug 08, 2007 at 03:49:00AM -0700, David Miller wrote:
> >
> > Not because I think it obviates your work, but rather because I'm
> > curious, could you test a TSO-in-hardware driver converted to
> > batching and see how TSO a
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 08/08/2007 05:44:02 PM:
> On Wed, Aug 08, 2007 at 03:01:45PM +0530, Krishna Kumar
([EMAIL PROTECTED]) wrote:
> > +static inline int get_skb(struct net_device *dev, struct Qdisc *q,
> > + struct sk_buff_head *blist, struct sk_buff **skbp)
> >
Hi Evgeniy,
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 08/08/2007 05:31:43 PM:
> > +int dev_change_tx_batch_skb(struct net_device *dev, unsigned long
new_batch_skb)
> > +{
> > + int ret = 0;
> > + struct sk_buff_head *blist;
> > +
> > + if (!dev->hard_start_xmit_batch) {
> > + /* Dr
Stephen Hemminger <[EMAIL PROTECTED]> wrote on 08/08/2007
04:29:46 PM:
> How do qdisc's that do rate control work now? Did you add logic to
> breakup batches for token bucket, etc.
My thought was that the code works identically to the current code except
in requeue cases. For requeue the existing
David Miller <[EMAIL PROTECTED]> wrote on 08/08/2007 04:19:00 PM:
> From: Krishna Kumar <[EMAIL PROTECTED]>
> Date: Wed, 08 Aug 2007 15:01:14 +0530
>
> > RESULTS: The performance improvement for TCP No Delay is in the range
of -8%
> >to 320% (with -8% being the sole negative), with many indivi
Hi Patrick,
Krishna Kumar2/India/IBM wrote on 07/23/2007 08:27:53 AM:
> Hi Patrick,
>
> Patrick McHardy <[EMAIL PROTECTED]> wrote on 07/22/2007 10:36:51 PM:
>
> > Krishna Kumar wrote:
> > > @@ -472,6 +474,9 @@ struct net_device
> > > void
Jamal,
This is silly. I am not responding to this type of presumptuous and
insulting mails.
Regards,
- KK
J Hadi Salim <[EMAIL PROTECTED]> wrote on 07/25/2007 12:58:20 AM:
> KK,
>
> On Tue, 2007-24-07 at 09:14 +0530, Krishna Kumar2 wrote:
>
> >
> > J Hadi Salim &
Hi Jamal,
J Hadi Salim <[EMAIL PROTECTED]> wrote on 07/23/2007 06:02:01 PM:
> Yes, and these results were sent to you as well a while back.
> When i get the time when i get back i will look em up in my test machine
> and resend.
Actually you have not sent netperf results with prep and without pr
Hi Evgeniy,
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 07/23/2007 04:14:28 PM:
> > +/*
> > + * dev_change_tx_batching - Enable or disable batching for a driver
that
> > + * supports batching.
> > + /* Check if new value is same as the current */
> > + if (!!(dev->features & NETIF_F_BATCH_O
Hi Evgeniy,
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 07/23/2007 04:18:26 PM:
> > static void ipoib_ib_handle_tx_wc(struct net_device *dev, struct ib_wc
*wc)
> > {
> > struct ipoib_dev_priv *priv = netdev_priv(dev);
> > + int i = 0, num_completions;
> > + int tx_ring_index = priv->t
32.73
--
Average:11205241224484 9.28%
There are three cases that degrade a little (upto -5.6%), but there are 13
cases
that improve, and many of those are in the 13% to over 100% (7 cases).
Thanks,
- KK
Krishna Kumar2/India/[EMAIL PROTECTED] wrote on 07/22/2007 02:34
> + if (dumpflg)
> + NLA_PUT_U32(skb, RTA_AGE, timeval_to_sec(&tv) - rt->rt6i_age);
> + else
> + NLA_PUT_U32(skb, RTA_AGE, rt->rt6i_age);
Makes more sense (and easy to understand) if you use :
if (dumpflg == RT6_GET_ROUTE_INFO)
...
so that your code does not break if someone c
Hi Sridhar,
Sridhar Samudrala <[EMAIL PROTECTED]> wrote on 07/23/2007 11:29:39 AM:
> Krishna Kumar2 wrote:
> > Hi Sridhar,
> >
> > Sridhar Samudrala <[EMAIL PROTECTED]> wrote on 07/20/2007 10:55:05 PM:
> >>> diff -ruNp org/include/net/pkt_sched.h new/
Hi Jamal,
J Hadi Salim <[EMAIL PROTECTED]> wrote on 07/22/2007 06:21:09 PM:
> My concern is there is no consistency in results. I see improvements on
> something which you say dont. You see improvement in something that
> Evgeniy doesnt etc.
Hmmm ? Evgeniy has not even tested my code to find som
Hi Evgeniy,
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 07/20/2007 06:24:23 PM:
> Hi Krishna.
>
> On Fri, Jul 20, 2007 at 12:01:49PM +0530, Krishna Kumar
([EMAIL PROTECTED]) wrote:
> > After fine-tuning qdisc and other changes, I modified IPoIB to use this
API,
> > and now get good gains. Summa
Hi Patrick,
Patrick McHardy <[EMAIL PROTECTED]> wrote on 07/22/2007 10:36:51 PM:
> Krishna Kumar wrote:
> > @@ -472,6 +474,9 @@ struct net_device
> > void *priv; /* pointer to private data */
> > int (*hard_start_xmit) (struct sk_buff *skb,
> >s
Hi Patrick,
Patrick McHardy <[EMAIL PROTECTED]> wrote on 07/22/2007 10:40:37 PM:
> Krishna Kumar wrote:
> > diff -ruNp org/include/linux/if_link.h rev2/include/linux/if_link.h
> > --- org/include/linux/if_link.h 2007-07-20 16:33:35.0 +0530
> > +++ rev2/include/linux/if_link.h 2007-07-
Hi Micheal,
"Michael S. Tsirkin" <[EMAIL PROTECTED]> wrote on 07/22/2007 03:11:36
PM:
> > + /*
> > +* Handle skbs completion from tx_tail to wr_id. It is possible to
> > +* handle WC's from earlier post_sends (possible multiple) in this
> > +* iteration as we move from tx_tail to wr
Hi Jamal,
J Hadi Salim <[EMAIL PROTECTED]> wrote on 07/21/2007 06:48:41 PM:
> >- Use a single qdisc interface to avoid code duplication and reduce
> > maintainability (sch_generic.c size reduces by ~9%).
> >- Has per device configurable parameter to turn on/off batching.
> >- qdi
Hi Sridhar,
Sridhar Samudrala <[EMAIL PROTECTED]> wrote on 07/20/2007 11:14:19 PM:
> > @@ -1566,7 +1605,7 @@ gso:
> > /* reset queue_mapping to zero */
> > skb->queue_mapping = 0;
> > rc = q->enqueue(skb, q);
> > - qdisc_run(dev);
> > + qdisc_run(dev,
Hi Sridhar,
Sridhar Samudrala <[EMAIL PROTECTED]> wrote on 07/20/2007 10:55:05 PM:
> > diff -ruNp org/include/net/pkt_sched.h new/include/net/pkt_sched.h
> > --- org/include/net/pkt_sched.h 2007-07-20 07:49:28.0 +0530
> > +++ new/include/net/pkt_sched.h 2007-07-20 08:30:22.0 +0
Hi Patrick,
Patrick McHardy <[EMAIL PROTECTED]> wrote on 07/20/2007 11:46:36 PM:
> Krishna Kumar wrote:
> > +static inline int get_skb(struct net_device *dev, struct Qdisc *q,
> > + struct sk_buff_head *blist,
> > + struct sk_buff **skbp)
> > +{
> > + if (likely(!blist) || (
Krishna Kumar2/India/IBM wrote on 07/21/2007 12:26:23 PM:
> Hi Patrick,
>
> Patrick McHardy <[EMAIL PROTECTED]> wrote on 07/20/2007 11:46:36 PM:
>
> > The check for tx_queue_len is wrong though,
> > its only a default which can be overriden and some qdiscs don't
Stephen Hemminger <[EMAIL PROTECTED]> wrote on 07/20/2007
09:52:03 PM:
> Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
> > Krishna Kumar2 wrote:
> > > Patrick McHardy <[EMAIL PROTECTED]> wrote on 07/20/2007 03:37:20 PM:
> > >
> > >
> >
Hi Evgeniy,
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 07/20/2007 06:24:23 PM:
> > After fine-tuning qdisc and other changes, I modified IPoIB to use this
API,
> > and now get good gains. Summary for TCP & No Delay: 1 process improves
for
> > all cases from 1.4% to 49.5%; 4 process has almost
(My Notes crashed when I hit the Send button, so not sure if this went
out).
__
Patrick McHardy <[EMAIL PROTECTED]> wrote on 07/20/2007 04:50:37 PM:
> 32 bytes? I count 16, - 4 for the pointer, so its 12 bytes of waste.
> If you'd use it for gso_skb it would come down to 8 bytes
Patrick McHardy <[EMAIL PROTECTED]> wrote on 07/20/2007 04:50:37 PM:
> 32 bytes? I count 16, - 4 for the pointer, so its 12 bytes of waste.
> If you'd use it for gso_skb it would come down to 8 bytes. struct
> net_device is a pig already, and there are better ways to reduce this
> than starting to
Patrick McHardy <[EMAIL PROTECTED]> wrote on 07/20/2007:
> I can't really argue about the numbers, but it seems to me that only
> devices which *usually* have a sufficient queue length will support
> this, and anyone setting the queue length of a gbit device to <16 is
> begging for trouble anyway.
Patrick McHardy <[EMAIL PROTECTED]> wrote on 07/20/2007 03:41:01 PM:
> Krishna Kumar wrote:
> > diff -ruNp org/net/sched/sch_generic.c new/net/sched/sch_generic.c
> > --- org/net/sched/sch_generic.c 2007-07-20 07:49:28.0 +0530
> > +++ new/net/sched/sch_generic.c 2007-07-20 08:30:22.000
Hi Patrick,
Patrick McHardy <[EMAIL PROTECTED]> wrote on 07/20/2007 04:50:37 PM:
> > I have a TODO comment in net-sysfs.c which is to catch this case.
> >
>
> I noticed that. Still wondering why it is important at all though.
I saw another mail of yours on the marc list on this same topic (which
Patrick McHardy <[EMAIL PROTECTED]> wrote on 07/20/2007 03:37:20 PM:
> Krishna Kumar wrote:
> > Support to turn on/off batching from /sys.
>
>
> rtnetlink support seems more important than sysfs to me.
Thanks, I will add that as a patch. The reason to add to sysfs is that
it is easier to change f
Hi Patrick,
Thanks for your comments.
Patrick McHardy <[EMAIL PROTECTED]> wrote on 07/20/2007 03:34:30 PM:
> The queue length can be changed through multiple interfaces, if that
> really is important you need to catch these cases too.
I have a TODO comment in net-sysfs.c which is to catch this
Stephen Hemminger <[EMAIL PROTECTED]> wrote on 07/20/2007
12:48:48 PM:
> You may see worse performance with batching in the real world when
> running over WAN's. Like TSO, batching will generate back to back packet
> trains that are subject to multi-packet synchronized loss. The problem is
that
>
Stephen Hemminger <[EMAIL PROTECTED]> wrote on 07/20/2007
12:48:48 PM:
> You may see worse performance with batching in the real world when
> running over WAN's. Like TSO, batching will generate back to back packet
> trains that are subject to multi-packet synchronized loss. The problem is
that
>
Attached file contains scripts for running tests and parsing results :
(See attached file: scripts.tar)
The result of a 10 run (average) TCP iperf (and 1 netperf for UDP) is
given below.
Thanks,
- KK
-
Test configurat
Hi Jamal,
J Hadi Salim <[EMAIL PROTECTED]> wrote on 07/03/2007 06:56:20 PM:
> On Mon, 2007-02-07 at 17:21 -0700, Michael Chan wrote:
>
> [Matt, please include the count in the fix per previous email]
> long answer:
> My goal with storing these values and computing them was to do certain
> things
Hi Dave,
I have copied him in these patches, so he doesn't have to read the netdev
to get them :)
- KK
David Miller <[EMAIL PROTECTED]> wrote on 06/19/2007 09:28:31 AM:
> From: Krishna Kumar2 <[EMAIL PROTECTED]>
> Date: Tue, 19 Jun 2007 09:05:28 +0530
>
> > Dave
Thanks Peter for testing out. I forgot to mention that I had also ran a 64
process
netperf (tcp & udp) on 2--CPU SMP systems without any issues.
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 with it.
thanks,
- KK
[EMAIL
Hi Peter,
Thanks for your feedback.
> > - netif_queue_stopped need not be called inside qdisc_restart as
> > it has been called already in qdisc_run() before the first skb
> > is sent, and in __qdisc_run() after each intermediate skb is
> > sent (note : we are the only sender, so the queue
Hi Jamal,
J Hadi Salim <[EMAIL PROTECTED]> wrote on 06/08/2007 04:44:06 PM:
> That should be fine as long as the sender is running the patched
> 2.6.22-rc4
Definitely :)
> Thats interesting - it is possible there is transient burstiness which
> fills up the ring.
> My observation of your result
> If the QDISC_RUNNING flag guarantees that only one CPU can call
> dev->hard_start_xmit(), then why do we need to hold netif_tx_lock
> for non-LLTX drivers?
I thought the correct use is to get this lock on clean_tx side which
can get called on a different cpu on rx (which also cleans up slots
for
Hi Evgeniy,
> Let me clarify: there are two possibilities to send data:
> 1. via batched sending, which runs via queue of packets and performs
> prepare call (which only setups some private flags, no work with
> hardware) and then sending call.
> 2. old xmit function (which seems to be unused by k
Hi Jamal,
> Would be nice to run three sets - but i think even one would be
> sufficiently revealing.
I will try multiple runs over the weekend. During the week, the systems
are used for other purposes too.
> I expect UDP to overwhelm the receiver. So the receiver needs a lot more
> tuning (like
sults, can you please say what
> hardware and setup was?
>
> The only real driver that has been changed is e1000 for now. KK is
> working on something infiniband related and i plan (if noone beats me)
> to get tg3 working. It would be nice if someone converted some 10G
> ethernet driver.
ou help out, when you post your results, can you please say what
> hardware and setup was?
>
> The only real driver that has been changed is e1000 for now. KK is
> working on something infiniband related and i plan (if noone beats me)
> to get tg3 working. It would be nice if someone
Sridhar Samudrala <[EMAIL PROTECTED]> wrote on 05/17/2007 03:14:41 AM:
> Krishna Kumar2 wrote:
> > Hi Sridhar,
> >
> > Sridhar Samudrala <[EMAIL PROTECTED]> wrote on 05/17/2007 03:42:03 AM:
> >
> >> AFAIK, gso_skb can be a list of skb
Hi Sridhar,
Sridhar Samudrala <[EMAIL PROTECTED]> wrote on 05/17/2007 03:42:03 AM:
> AFAIK, gso_skb can be a list of skb's. Can we add a list
> to another list using __skb_queue_head()?
> Also, if gso_skb is a list of multiple skb's, i think the
> count needs to be decremented by the number of se
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 05/11/2007 03:02:02 PM:
> On Fri, May 11, 2007 at 02:48:14PM +0530, Krishna Kumar2
([EMAIL PROTECTED]) wrote:
> > > And what if you have thousand(s) of packets queued and first one has
> > > failed, requeing all the rest o
Hi all,
Very preliminary testing with 20 procs on E1000 driver gives me following
result:
skbszOrg BW New BW % Org demand
New Demand %
32 315.98 347.489.97% 21090
20958 0.62%
96
1 - 100 of 120 matches
Mail list logo
