* Re: [PATCH 1/2] r8169: Rx FIFO overflow fixes.
From: David Miller @ 2011-12-05 23:45 UTC (permalink / raw)
To: romieu
Cc: booster, hayeswang, jrnieder, eric.dumazet, netdev, nic_swsd,
linux-kernel, armin.kazmi
In-Reply-To: <20111205063045.GA3103@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Mon, 5 Dec 2011 07:30:45 +0100
> Realtek has specified that the post 8168c gigabit chips and the post
> 8105e fast ethernet chips recover automatically from a Rx FIFO overflow.
> The driver does not need to clear the RxFIFOOver bit of IntrStatus and
> it should rather avoid messing it.
>
> The implementation deserves some explanation:
> 1. events outside of the intr_event bit mask are now ignored. It enforces
> a no-processing policy for the events that either should not be there
> or should be ignored.
>
> 2. RxFIFOOver was already ignored in rtl_cfg_infos[RTL_CFG_1] for the
> whole 8168 line of chips with two exceptions:
> - RTL_GIGA_MAC_VER_22 since b5ba6d12bdac21bc0620a5089e0f24e362645efd
> ("use RxFIFO overflow workaround for 8168c chipset.").
> This one should now be correctly handled.
> - RTL_GIGA_MAC_VER_11 (8168b) which requires a different Rx FIFO
> overflow processing.
>
> Though it does not conform to Realtek suggestion above, the updated
> driver includes no change for RTL_GIGA_MAC_VER_12 and RTL_GIGA_MAC_VER_17.
> Both are 8168b. RTL_GIGA_MAC_VER_12 is common and a bit old so I'd rather
> wait for experimental evidence that the change suggested by Realtek really
> helps or does not hurt in unexpected ways.
>
> Removed case statements in rtl8169_interrupt are only 8168 relevant.
>
> 3. RxFIFOOver is masked for post 8105e 810x chips, namely the sole 8105e
> (RTL_GIGA_MAC_VER_30) itself.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: hayeswang <hayeswang@realtek.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tcp: take care of misalignments
From: David Miller @ 2011-12-05 23:45 UTC (permalink / raw)
To: eric.dumazet; +Cc: subramanian.vijay, therbert, netdev
In-Reply-To: <1323024668.2762.163.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 04 Dec 2011 19:51:08 +0100
> [PATCH net-next] tcp: fix tcp_trim_head()
>
> commit f07d960df3 (tcp: avoid frag allocation for small frames)
> breaked assumption in tcp stack that skb is either linear (skb->data_len
> == 0), or fully fragged (skb->data_len == skb->len)
>
> tcp_trim_head() made this assumption, we must fix it.
>
> Thanks to Vijay for providing a very detailed explanation.
>
> Reported-by: Vijay Subramanian <subramanian.vijay@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCHv3 net-next 1/4] if_ether.h: Add IEEE 802.1 Local Experimental Ethertype 1.
From: David Miller @ 2011-12-05 23:46 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, alexey.orishko, eric.dumazet
In-Reply-To: <1323033775-3496-1-git-send-email-sjur.brandeland@stericsson.com>
From: Sjur Brændeland <sjur.brandeland@stericsson.com>
Date: Sun, 4 Dec 2011 22:22:52 +0100
> Add EthType 0x88b5.
> This Ethertype value is available for public use for prototype and
> vendor-specific protocol development,as defined in Amendment 802a
> to IEEE Std 802.
>
> Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCHv3 net-next 2/4] caif: Add support for CAIF over CDC NCM USB interface
From: David Miller @ 2011-12-05 23:46 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, alexey.orishko, eric.dumazet
In-Reply-To: <1323033775-3496-2-git-send-email-sjur.brandeland@stericsson.com>
From: Sjur Brændeland <sjur.brandeland@stericsson.com>
Date: Sun, 4 Dec 2011 22:22:53 +0100
> NCM 1.0 does not support anything but Ethernet framing, hence
> CAIF payload will be put into Ethernet frames.
>
> Discovery is based on fixed USB vendor 0x04cc (ST-Ericsson),
> product-id 0x230f (NCM). In this variant only CAIF payload is sent over
> the NCM interface.
>
> The CAIF stack (cfusbl.c) will when USB interface register first check if
> we got a CDC NCM USB interface with the right VID, PID.
> It will then read the device's Ethernet address and create a 'template'
> Ethernet TX header, using a broadcast address as the destination address,
> and EthType 0x88b5 (802.1 Local Experimental - vendor specific).
>
> A protocol handler for 0x88b5 is setup for reception of CAIF frames from
> the CDC NCM USB interface.
>
> Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCHv3 net-next 3/4] caif: Add support for flow-control on device's tx-queue
From: David Miller @ 2011-12-05 23:46 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, alexey.orishko, eric.dumazet
In-Reply-To: <1323033775-3496-3-git-send-email-sjur.brandeland@stericsson.com>
From: Sjur Brændeland <sjur.brandeland@stericsson.com>
Date: Sun, 4 Dec 2011 22:22:54 +0100
> Flow control is implemented by inspecting the qdisc queue length
> in order to detect potential overflow on the TX queue. When a threshold
> is reached flow-off is sent upwards in the CAIF stack. At the same time
> the skb->destructor is hi-jacked by orphaning the SKB and the original
> destructor is replaced with a "flow-on" callback. When the "hi-jacked"
> SKB is consumed the queue should be empty, and the "flow-on" callback
> is called and xon is sent upwards in the CAIF stack.
>
> Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCHv3 net-next 4/4] caif: Stash away hijacked skb destructor and call it later
From: David Miller @ 2011-12-05 23:46 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, alexey.orishko, eric.dumazet
In-Reply-To: <1323033775-3496-4-git-send-email-sjur.brandeland@stericsson.com>
From: Sjur Brændeland <sjur.brandeland@stericsson.com>
Date: Sun, 4 Dec 2011 22:22:55 +0100
> This patch adds functionality for avoiding orphaning SKB too early.
> The original skb is stashed away and the original destructor is called
> from the hi-jacked flow-on callback. If CAIF interface goes down and a
> hi-jacked SKB exists, the original skb->destructor is restored.
>
> Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bql: fix CONFIG_XPS=n build
From: David Miller @ 2011-12-05 23:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, therbert
In-Reply-To: <1323038280.14707.5.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 04 Dec 2011 23:38:00 +0100
> netdev_queue_release() should be called even if CONFIG_XPS=n
> to properly release device reference.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] unix: Add /proc/net/unix_peers file
From: David Miller @ 2011-12-05 23:47 UTC (permalink / raw)
To: xemul; +Cc: netdev, eric.dumazet
In-Reply-To: <4EDC9C07.6070904@parallels.com>
From: Pavel Emelyanov <xemul@parallels.com>
Date: Mon, 05 Dec 2011 14:25:11 +0400
> On 12/04/2011 10:25 PM, David Miller wrote:
>> Please extend the netlink socket dumping so that it works with
>> AF_UNIX sockets and subsequently added the necessary netlink
>> attribute to provide the peer value.
>
> OK, will do it this way. AFAIU you're talking about the NETLINK_INET_DIAG, right?
Yes.
If that framework, for some reason, doesn't fit AF_UNIX sockets well
or needs to be genericized, please feel free to do whatever you think
is necessary to address that.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] tcp: remove TCP_OFF and TCP_PAGE macros
From: David Miller @ 2011-12-05 23:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: joe, netdev
In-Reply-To: <1323083235.2670.44.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 05 Dec 2011 12:07:15 +0100
> Le dimanche 04 décembre 2011 à 09:20 -0800, Joe Perches a écrit :
>> And maybe the TCP_OFF and TCP_PAGE macros should be removed.
>>
>
> Agreed, thanks.
>
> [PATCH net-next] tcp: remove TCP_OFF and TCP_PAGE macros
>
> As mentioned by Joe Perches, TCP_OFF() and TCP_PAGE() macros are
> useless.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v7 10/10] Disable task moving when using kernel memory accounting
From: KAMEZAWA Hiroyuki @ 2011-12-06 0:07 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, paul-inf54ven1CmVyaH7bEyXVA,
lizf-BthXqXjhjHXQFUHtdCDX3A, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, gthelen-hpIqsD4AKlfQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
kirill-oKw7cIdHH8eLwutG50LtGA, avagin-bzQdu9zFT3WakBO8gow8eQ,
devel-GEFAQzZX7r8dnm+yROfE0A, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4EDC8C6D.2070001-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
On Mon, 5 Dec 2011 07:18:37 -0200
Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
> On 12/05/2011 12:18 AM, KAMEZAWA Hiroyuki wrote:
> > On Fri, 2 Dec 2011 16:11:56 -0200
> > Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
> >
> >> On 11/30/2011 12:22 AM, KAMEZAWA Hiroyuki wrote:
> >>> On Tue, 29 Nov 2011 21:57:01 -0200
> >>> Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
> >>>
> >>>> Since this code is still experimental, we are leaving the exact
> >>>> details of how to move tasks between cgroups when kernel memory
> >>>> accounting is used as future work.
> >>>>
> >>>> For now, we simply disallow movement if there are any pending
> >>>> accounted memory.
> >>>>
> >>>> Signed-off-by: Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> >>>> CC: Hiroyouki Kamezawa<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> >>>> ---
> >>>> mm/memcontrol.c | 23 ++++++++++++++++++++++-
> >>>> 1 files changed, 22 insertions(+), 1 deletions(-)
> >>>>
> >>>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> >>>> index a31a278..dd9a6d9 100644
> >>>> --- a/mm/memcontrol.c
> >>>> +++ b/mm/memcontrol.c
> >>>> @@ -5453,10 +5453,19 @@ static int mem_cgroup_can_attach(struct cgroup_subsys *ss,
> >>>> {
> >>>> int ret = 0;
> >>>> struct mem_cgroup *memcg = mem_cgroup_from_cont(cgroup);
> >>>> + struct mem_cgroup *from = mem_cgroup_from_task(p);
> >>>> +
> >>>> +#if defined(CONFIG_CGROUP_MEM_RES_CTLR_KMEM)&& defined(CONFIG_INET)
> >>>> + if (from != memcg&& !mem_cgroup_is_root(from)&&
> >>>> + res_counter_read_u64(&from->tcp_mem.tcp_memory_allocated, RES_USAGE)) {
> >>>> + printk(KERN_WARNING "Can't move tasks between cgroups: "
> >>>> + "Kernel memory held.\n");
> >>>> + return 1;
> >>>> + }
> >>>> +#endif
> >>>
> >>> I wonder....reading all codes again, this is incorrect check.
> >>>
> >>> Hm, let me cralify. IIUC, in old code, "prevent moving" is because you hold
> >>> reference count of cgroup, which can cause trouble at rmdir() as leaking refcnt.
> >> right.
> >>
> >>> BTW, because socket is a shared resource between cgroup, changes in mm->owner
> >>> may cause task cgroup moving implicitly. So, if you allow leak of resource
> >>> here, I guess... you can take mem_cgroup_get() refcnt which is memcg-local and
> >>> allow rmdir(). Then, this limitation may disappear.
> >>
> >> Sorry, I didn't fully understand. Can you clarify further?
> >> If the task is implicitly moved, it will end up calling can_attach as
> >> well, right?
> >>
> > I'm sorry that my explanation is bad.
> >
> > You can take memory cgroup itself's reference count by mem_cgroup_put/get.
> > By getting this, memory cgroup object will continue to exist even after
> > its struct cgroup* is freed by rmdir().
> >
> > So, assume you do mem_cgroup_get()/put at socket attaching/detatching.
> >
> > 0) A task has a tcp socekts in memcg0.
> >
> > task(memcg0)
> > +- socket0 --> memcg0,usage=4096
> >
> > 1) move this task to memcg1
> >
> > task(memcg1)
> > +- socket0 --> memcg0,usage=4096
> >
> > 2) The task create a new socket.
> >
> > task(memcg1)
> > +- socekt0 --> memcg0,usage=4096
> > +- socket1 --> memcg1,usage=xxxx
> >
> > Here, the task will hold 4096bytes of usage in memcg0 implicitly.
> >
> > 3) an admin removes memcg0
> > task(memcg1)
> > +- socket0 -->memcg0, usage=4096<-----(*)
> > +- socket1 -->memcg1, usage=xxxx
> >
> > (*) is invisible to users....but this will not be very big problem.
> >
> Hi Kame,
>
> Thanks for the explanation.
>
> Hummm, Do you think that by doing it, we get rid of the need of moving
> sockets to another memcg when the task is moved? So in my original
> patchset, if you recall, I wanted to keep a socket forever in the same
> cgroup. I didn't, because then rmdir would be blocked.
>
> By using this memcg reference trick, both can be achieved. What do you
> think ?
I think so. Using mem_cgroup_put/get is a way. Could you try ?
Thanks,
-Kame
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* ©Call Tel : +44-701-004-8163
From: "©Simon Cole" @ 2011-12-06 1:58 UTC (permalink / raw)
Nokia awarded you the sum of 1,000,000.00 Pounds Send Names,address,Sex,
Age, Tel.Mr Simon Cole. Email :simonnok@bitscn.net. Tel : +44-701-004-8163
^ permalink raw reply
* Re: Time in Queue, bufferbloat, and... our accidentally interplanetary network
From: Adrian Chadd @ 2011-12-06 2:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: Dave Taht, bloat, bloat-devel, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless
In-Reply-To: <1323082774.2670.40.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Hi,
For what it's worth, I've also been tinkering with time-in-queue for
the wifi queue management in FreeBSD. I don't have anything public
yet. What I have done actually seems to work quite well, when doing TX
queue time-in-queue management. (I'm ignoring RX queue management for
now.)
Yes, I think a weighted random drop with both time-in-queue and queue
depth would work well. I haven't sat down to model what it'd look like
given some traffic profiles.
I'll be sure to post some patches and results when I have them. :)
Adrian
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [GIT PULL v3] Open vSwitch
From: Zhi Yong Wu @ 2011-12-06 2:12 UTC (permalink / raw)
To: Jesse Gross
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
David S. Miller
In-Reply-To: <CAEP_g=-SAdXf33qP9Y=wS0QkG1OKBVXFBHTYgqD+8HgZznbLuQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Dec 6, 2011 at 1:37 AM, Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org> wrote:
> On Sun, Dec 4, 2011 at 7:32 PM, Zhi Yong Wu <zwu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Although this series of patchset is a bit large, therefore their codes
>> aren't directly pasted here, but if anyone find some issues in the
>> codes, how will we point out them?
>
> I also sent out the actual patches that are referenced in this pull
> request to the mailing list, so that would be the best place to
> provide comments. For example, this is the first patch in the series:
> http://marc.info/?l=linux-netdev&m=132293763127660&w=2
Got it, thanks.
--
Regards,
Zhi Yong Wu
^ permalink raw reply
* Re: Understanding HFSC
From: John A. Sullivan III @ 2011-12-06 3:42 UTC (permalink / raw)
To: Michal Soltys; +Cc: netdev
In-Reply-To: <4EDB69C7.6080209@ziu.info>
Thank you very much, Michal, for taking the time to answer these in depth. I know they are detailed and long questions and I'm sure you have other demands on your time! I'll respond in-line - John
----- Original Message -----
> From: "Michal Soltys" <soltys@ziu.info>
> To: "John A. Sullivan III" <jsullivan@opensourcedevel.com>
> Cc: netdev@vger.kernel.org
> Sent: Sunday, December 4, 2011 7:38:31 AM
> Subject: Re: Understanding HFSC
>
> On 11-12-04 05:57, John A. Sullivan III wrote:
><snip>
> > One of the most confusing bits to me is, does the m1 rate apply to
> > each flow handled by the class or only to the entire class once it
> > becomes active?
>
> Where a packet lands is (generally) determined by tc filters and/or
> iptables' mark/classify targets. All the packets that end in some
> leaf
> node, are governed by that node's realtime service curve, and at
> times
> when that criterion is not used - at the ratio of virtual times
> (coming
> from linkshare service curves) between that node and its siblings.
> Regardless of curve used - smallest vt (linkshare criterion) or
> smallest
> dt from all eligible (realtime criterion) wins, and the leaf with one
> will fulfill the dequeue call.
>
> If you need more fine grained control "below" such leaf node - you
> need
> to either use deeper hierarchy with presumably "simpler" qdiscs
> attached
> (but more complex marking setup), or shallower hierarchy with more
> elaborate qdiscs attached. Think of work conserving qdiscs such as:
> sfq,
> drr - paired with appropriate tc filters (tc-flow perhaps ?) as
> needed.
Hmm . . . If I understand your response correctly, that's the answer I was hoping was not the case :( It sounds like the queue is ignorant of the flow, i.e., it only knows that it has a packet and wants to know if it should dequeue it. It has no idea that packet 1 is from an existing conversation and packet 2 is from a new one that needs to be jumped to the head of the overall queue if packet 1 and 2 are in the same leaf class. Let me illustrate with two separate examples to see if I understand. In the first example, we have periodic traffic such as VoIP and, in the second, we have bulk traffic which is being sent as fast as the originating system can send it. In both cases, let's assume there is another class which is always backlogged.
In the first case, we are sending 222 byte RTP VoIP packets every 20ms. Thus, we set rt umax to 222, dmax to 5ms, and rate to some number more than sufficient to handle VoIP. I think the umax/dmax setting means we reduce deadline time for the RTP packet but only for the first one. So I start one VoIP conversation, the first packet is "accelerated" and the rest keep arriving in 20ms intervals. These are having their deadline times calculated according to the rt rate and not the accelerated umax/dmax slope. 1ms after one of those RTP packets arrives, an RTP from a new VoIP session arrives. Is deadline calculated for this first packet of the new conversation from umax/dmax or rate? I would hope it would be umax/dmax but, since it sounds like the class does not distinguish between separa
te flows, it will be calculated at rate since we have already exceeded the intersection of m1 and m2. Hmm . . . or does the time between the VoIP packets arriving every 20ms mean the queue actually is no longer backlogged and therefore resets the service curve so that each packet is effectively on the m1 slope rather than the m2 slope?
So let's go to the second scenario which does not involve periodic packets but a constant flow. This is the example someone cited of using HFSC to accelerate the text portion of a web page. So, we have typical text of 80kbits and want no more than 100ms delay serving that initial bit of text. So rt umax 80kbits dmax 100ms rate 500kbits Someone connects to the web server and we serve the first 80kbits at 800kbits per second and start streaming a large embedded video at 500kbits per second. While that video is being sent, a second user connects to the web server. Is there initial 80kbits of text sent at 800kbits per second or 500?
>
> Btw - check out the very latest iproute2 tree - there're fresh
> tc-hfsc(7) and tc-stab(8) manuals added. I tried to make them as
> detailed as possible, but I might have overshot a bit - so opinion of
> someone getting into hfsc territory is invaluable. You can read them
> (if
> installing fresh iproute2 is out of question) with simple:
>
> nroff -mandoc -rLL=<width>n <page> | less
>
> http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=blob_plain;f=man/man7/tc-hfsc.7;hb=HEAD
> http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=blob_plain;f=man/man8/tc-stab.8;hb=HEAD
>
><snip>
Thanks. I think I already read this once or twice on-line but read it again from cover to cover from your links to ensure I had the latest and greatest. Each time, it makes more sense - John
^ permalink raw reply
* Re: More understanding HFSC
From: John A. Sullivan III @ 2011-12-06 4:07 UTC (permalink / raw)
To: Michal Soltys; +Cc: netdev
In-Reply-To: <4EDD4332.7090109@ziu.info>
----- Original Message -----
> From: "Michal Soltys" <soltys@ziu.info>
> To: "John A. Sullivan III" <jsullivan@opensourcedevel.com>
> Cc: netdev@vger.kernel.org
> Sent: Monday, December 5, 2011 5:18:26 PM
> Subject: Re: More understanding HFSC
>
> On 11-12-04 07:12, John A. Sullivan III wrote:
><snip>
> > Very important for my understanding, specifying rt and ls in the
> > same
> > class is NOT the mechanism used for decoupling latency guarantees
> > from
> > bandwidth allocations. That is simply specifying that available
> > bandwidth will be obtained in a different proportion than the
> > guaranteed bandwidth.
>
> yes
>
> > The decoupling of latency from bandwidth happens by having a
> > dilinear
> > service curve, i.e., specifying either m1, d, and m2 or specifying
> > umax, dmax, and rate where umax/dmax != rate. Is that correct?
>
> yes
>
> > So, it then seems like: virtual time is dependent upon ls
>
> yes
>
> > eligible time is dependent upon available bandwidth as determined
> > by
> > ul and ls
>
> no, eligible curve is derived from RT curve. For linear and concave
> curves it's the same as RT curve. For convex RT - eligible curve is
> linear using RT's second slope. The time calculated from it is
> relative
> to packets' heads - essentially answering question: which packets
> should
> be in transit already by current time (and for convex - which should
> be
> sent earlier, so when the curve is violated later by some other
> class(es), everything remains fine with reference to the amount of
> service received by some time). RT ignores LS/UL.
>
> > deadline time is dependent on the curve which is why a dilinear
> > curve
> > can be used to "jump the queue" so to speak or to drop back in the
> > queue.
>
> deadline curve is also derived from RT curve, and it's always of the
> same parameters. But packets tails are used here - essentialy
> answering
> question: what packet should go first (as only 1 can be send at a
> time
> after all). No relevance to LS/UL in any way or form either.
>
> So more correct way to say is: RT *is* deadline and eligible.
Ah, OK. I think I'm starting to get it. I had read that but had not put it all together. It all makes great sense. So eligible time is answering the question of what packets should we start sending (hence looking at the beginning of the packet) and deadline is answering by when must the packet be fully delivered (hence looking at the tail).
<snip>
> later, though you might want to update the questions first by now :)
<snip>
I don't think what I've learned changes anything that I outlined in the rest of the email but I think I understand it a whole lot better now. Thanks - John
^ permalink raw reply
* Latency difference between fifo and pfifo_fast
From: John A. Sullivan III @ 2011-12-06 4:10 UTC (permalink / raw)
To: netdev
In-Reply-To: <8f05fdb0-6e4c-4adf-b8d1-bd67a0dc114f@jasiiieee>
Hello, all. We are trying to minimize latency on our iSCSI SAN. The network is entirely dedicated to the iSCSI traffic. Since all the traffic is the same, would it make sense to change the qdisc for that interface to fifo from the default pfifo_fast or is the latency difference between the two completely negligible? Thanks - John
^ permalink raw reply
* Shaping TCP ACK packets
From: John A. Sullivan III @ 2011-12-06 4:18 UTC (permalink / raw)
To: netdev
In-Reply-To: <b7c7ae97-0030-4397-a1e3-ec29babdff4d@jasiiieee>
Hello, all. I've seen several sites recommend prioritizing TCP ACK packets using tc. Is that a good idea? I have two reservations:
1) If my line is congested, isn't delaying ACKs a good way to slow down the conversation? Accelerating ACKs under congestion sounds a bit like stuffing more food in my mouth when I'm already choking.
2) By messing with normal coordination of TCP, do I risk making a mess. Specifically, can I create problems with out of order packet delivery - send an ACK before the packet which should have preceded it? I suppose in a well behaved protocol that wouldn't happen but I'm not sure. Thanks - John
^ permalink raw reply
* Patch is wrong
From: Michael Wang @ 2011-12-06 3:27 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, Ram Pai, Flavio Leitner, Jeff Kirsher,
Jesse Brandeburg
Hi, David
I want to argue about this patch:
http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=commit;h=09357b00255c233705b1cf6d76a8d147340545b8
I am the author of this patch, and Jeff only change 0, 1 to false and
true, now he become the author.
This is the original patch:
http://sourceforge.net/mailarchive/forum.php?thread_name=20111118152002.19d3cabc%40asterix.rh&forum_name=e1000-devel
This is my first patch and the result really hurt me, please check and
maintain the justice.
Thanks,
Michael Wang
^ permalink raw reply
* Re: `ip addr show' shows maximum of 56 addresses?
From: Ben Hutchings @ 2011-12-06 3:48 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ben Jencks, netdev
In-Reply-To: <1323129923.2887.51.camel@bwh-desktop>
[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]
Eric Dumazet wrote:
> Le lundi 05 décembre 2011 à 16:12 -0500, Ben Jencks a écrit :
> > I'm finding that ip addr show will only give me up to 56 addresses:
> >
> > $ ip -6 addr show lo
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
> > inet6 ::1/128 scope host
> > valid_lft forever preferred_lft forever
> > $ for i in `seq 55` ; do sudo ip addr del fd9a:704e:4d65:136d::`printf '%x\n' $i`/128 dev lo ; done
> > $ ip addr show lo | grep inet6 | wc -l
> > 56
> > $ ip addr show lo | grep ' ::1'
> > inet6 ::1/128 scope host
> > $ sudo ip addr add fd9a:704e:4d65:136d::`printf '%x\n' 56`/128 dev lo
> > $ ip addr show lo | grep inet6 | wc -l
> > 56
> > $ ifconfig lo | grep inet6 | wc -l
> > 57
> > $ ip addr show lo | grep ' ::1'
> > <no output>
> >
> > It doesn't even help to specify the address explicitly:
> >
> > $ ip addr show dev lo to ::1
> > <no output>
> >
> > (Ubuntu kernel 2.6.32, tested with both distributed and latest git iproute2)
> >
> > I searched for this issue, and even looked in the iproute2/ip/ipaddress.c and couldn't find any explicit limits. Is there a maximum netlink message size causing problems?
> >
> > Sorry if this question is too user-ish for a dev list, but both linux-net and lartc looked dead.
> >
> > Thanks,
> > -Ben--
>
> This was fixed two years ago by commit bcd323262a94b14b in 2.6.33
> (ipv6: Allow inet6_dump_addr() to handle more than 64 addresses)
Seems like a candidate for 2.6.32.y. I don't think it depends on any of
your other changes for 2.6.33, does it?
Ben.
--
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Patch is wrong
From: David Miller @ 2011-12-06 4:39 UTC (permalink / raw)
To: wangyun; +Cc: netdev, linuxram, fbl, jeffrey.t.kirsher, jesse.brandeburg
In-Reply-To: <4EDD8B8C.7000905@linux.vnet.ibm.com>
From: Michael Wang <wangyun@linux.vnet.ibm.com>
Date: Tue, 06 Dec 2011 11:27:08 +0800
> I am the author of this patch, and Jeff only change 0, 1 to false and
> true, now he become the author.
Take it up with Jeff, I pulled the change from his GIT tree and that's
where the authorship information came from.
Unfortunately, it cannot be fixed as it's already pushed out to my
tree.
^ permalink raw reply
* WebCT Administrator
From: Luz Romero @ 2011-12-06 5:03 UTC (permalink / raw)
Your mailbox has exceeded the storage limit which is 20GB as set by your administrator, you are currently running on 20.9GB, you may not be able to send or receive new mail until you re-validate your mailbox.To re-validate your mailbox please <http://kbjomss.tk/> CLICK HERE<http://kbjomss.tk/>
Thanks
System Administrator.
WebCT Administrator
^ permalink raw reply
* Re: Patch is wrong
From: Michael Wang @ 2011-12-06 5:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linuxram, fbl, jeffrey.t.kirsher, jesse.brandeburg
In-Reply-To: <20111205.233937.1669740069700653317.davem@davemloft.net>
On 12/06/2011 12:39 PM, David Miller wrote:
> From: Michael Wang <wangyun@linux.vnet.ibm.com>
> Date: Tue, 06 Dec 2011 11:27:08 +0800
>
>> I am the author of this patch, and Jeff only change 0, 1 to false and
>> true, now he become the author.
>
> Take it up with Jeff, I pulled the change from his GIT tree and that's
> where the authorship information came from.
>
Hi, David
Jeff know what happened, he promised to add my and Flavio's
signed-off-by in the pre-mail.
It's easy to see from the mail that who is the author, and I have reply
just after Jeff's patch send out to you, I add my signed-off-by and
From, but no one care.
I know you are all experts and have lots of patches in community, you
won't care such a small patch's author, but this is very important for
me because this is my first patch, it's stand for my passion and will to
join the community.
I know it will cost you many works, but I still have to ask you to
replace this patch, because this will become a mistake in Linux, which
will make me sad each time I saw it on git log.
Thanks & Best regards
Michael Wang
> Unfortunately, it cannot be fixed as it's already pushed out to my
> tree.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Patch is wrong
From: David Miller @ 2011-12-06 5:25 UTC (permalink / raw)
To: wangyun; +Cc: netdev, linuxram, fbl, jeffrey.t.kirsher, jesse.brandeburg
In-Reply-To: <4EDDA413.1080106@linux.vnet.ibm.com>
From: Michael Wang <wangyun@linux.vnet.ibm.com>
Date: Tue, 06 Dec 2011 13:11:47 +0800
> I know it will cost you many works, but I still have to ask you to
> replace this patch, because this will become a mistake in Linux, which
> will make me sad each time I saw it on git log.
It is simply not possible without screwing over every single person
who follows my tree.
If I go in and pull out the change, then everyone who follows my
tree will have a corrupt tree.
Sorry, mistakes happen, and once they are pushed out to GIT trees
used by lots of people we have to live with it.
^ permalink raw reply
* Re: [PATCH] net: Silence seq_scale() unused warning
From: David Miller @ 2011-12-06 5:31 UTC (permalink / raw)
To: sboyd; +Cc: linux-kernel, netdev
In-Reply-To: <1323109796-31084-1-git-send-email-sboyd@codeaurora.org>
From: Stephen Boyd <sboyd@codeaurora.org>
Date: Mon, 5 Dec 2011 10:29:56 -0800
> On a CONFIG_NET=y build
>
> net/core/secure_seq.c:22: warning: 'seq_scale' defined but not
> used
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> I don't know how realistic this configuration is, but here it goes.
Just test INET all by itself, IPV6 will always need the INET
infrastructure for hash tables and inet socket management even in the
extremely unlikely event that we make ipv4 independently selectable at
some point.
^ permalink raw reply
* Re: [PATCH] netback: Fix alert message.
From: David Miller @ 2011-12-06 5:33 UTC (permalink / raw)
To: Ian.Campbell; +Cc: wei.liu2, xen-devel, netdev
In-Reply-To: <1323104325.23681.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 5 Dec 2011 16:58:45 +0000
> On Mon, 2011-12-05 at 16:57 +0000, Wei Liu wrote:
>> The original message in netback_init was 'kthread_run() fails', which should be
>> 'kthread_create() fails'.
>>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Applied, thanks.
^ 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