On Fri, 2018-07-06 at 16:38 -0700, Alexei Starovoitov wrote:
> On Fri, Jul 06, 2018 at 08:44:24PM +0000, Waskiewicz Jr, Peter wrote:
> > On Fri, 2018-07-06 at 09:30 -0700, Alexei Starovoitov wrote:
> > > On Thu, Jul 05, 2018 at 10:18:23AM -0700, Jakub Kicinski wrote:
> > &
On Fri, 2018-07-06 at 09:30 -0700, Alexei Starovoitov wrote:
> On Thu, Jul 05, 2018 at 10:18:23AM -0700, Jakub Kicinski wrote:
> >
> > I'm also not 100% on board with the argument that "future" FW can
> > reshuffle things whatever way it wants to. Is the assumption that
> > future ASICs/FW will b
On 9/28/17 2:23 PM, John Fastabend wrote:
> [...]
>
>> I'm pretty sure I misunderstood what you were going after with
>> XDP_REDIRECT reserving the headroom. Our use case (patches coming in a
>> few weeks) will populate the headroom coming out of the driver to XDP,
>> and then once the XDP progra
On 9/28/17 12:59 PM, Andy Gospodarek wrote:
> On Thu, Sep 28, 2017 at 1:59 AM, Waskiewicz Jr, Peter
> wrote:
>> On 9/26/17 10:21 AM, Andy Gospodarek wrote:
>>> On Mon, Sep 25, 2017 at 08:50:28PM +0200, Daniel Borkmann wrote:
>>>> On 09/25/201
On 9/26/17 10:21 AM, Andy Gospodarek wrote:
> On Mon, Sep 25, 2017 at 08:50:28PM +0200, Daniel Borkmann wrote:
>> On 09/25/2017 08:10 PM, Andy Gospodarek wrote:
>> [...]
>>> First, thanks for this detailed description. It was helpful to read
>>> along with the patches.
>>>
>>> My only concern abou
On 9/13/17 7:24 PM, Brown, Aaron F wrote:
>> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
>> Of Christophe JAILLET
>> Sent: Monday, August 28, 2017 10:13 AM
>> To: Waskiewicz Jr, Peter ; Kirsher, Jeffrey T
>>
>> Cc:
On 8/28/17 2:06 AM, Dan Carpenter wrote:
> On Sun, Aug 27, 2017 at 11:16:06PM +0000, Waskiewicz Jr, Peter wrote:
>> On 8/27/17 3:26 PM, SF Markus Elfring wrote:
>>> From: Markus Elfring
>>> Date: Sun, 27 Aug 2017 21:18:37 +0200
>>>
>>> Omit an extra me
On 8/27/17 9:25 PM, Bassam Alsanie wrote:
> Hello everyone,
> I looking into a good way (stable and compatible with large number of
> distros) to get the arp/nd cache from kernel to user space, for both
> IP4 and IP6.
>
> It seem IOCTL (SIOCGARP) can't do that, you can only get MAC address
> from
On 8/27/17 3:26 PM, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 27 Aug 2017 21:18:37 +0200
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
Did coccinelle trip on the message or the fact yo
On 8/27/17 2:42 AM, Christophe JAILLET wrote:
> Check memory allocation failures and return -ENOMEM in such cases, as
> already done for other memory allocations in this function.
>
> This avoids NULL pointers dereference.
>
> Signed-off-by: Christophe JAILLET
> ---
> drivers/net/ethernet/inte
On 8/25/17 11:25 AM, Jacob Keller wrote:
> Under some circumstances, such as with many stacked devices, it is
> possible that dev_hard_start_xmit will bundle many packets together, and
> mark them all with xmit_more.
>
> Most drivers respond to xmit_more by skipping tail bumps on packet
> rings, o
On 8/25/17 10:59 AM, Jesper Dangaard Brouer wrote:
> On Fri, 25 Aug 2017 14:24:28 +
> "Waskiewicz Jr, Peter" wrote:
>
>> On 8/25/17 5:19 AM, Jesper Dangaard Brouer wrote:
>>>>
>>>> Tested with Intel XL710 NIC with Cisco 3172 switch.
On 8/25/17 5:19 AM, Jesper Dangaard Brouer wrote:
>>
>> Tested with Intel XL710 NIC with Cisco 3172 switch.
>>
>> It would be even slightly better if the irqbalance service is turned
>> off outside.
>
> Yes, if you don't turn-off (kill) irqbalance it will move around the
> IRQs behind your back...
> > + fprintf(stderr, "\nNOTE: CLASSID is parsed as hexidecimal
> > +input.\n");
>
> s/hexidecimal/hexadecimal/g (?)
Gah! Thanks Jarek, I can correct and resend.
-PJ Waskiewicz
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
> Sorry, can't change the api, update the documentation instead.
Yes, this is much more reasonable. I'll send a patch shortly to do
that.
Thanks
-PJ Waskiewicz
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
> From: PJ Waskiewicz <[EMAIL PROTECTED]>
>
> Using strtoul with a base of 16 converts flowid 10 into 0x10,
> which makes it flowid 16. This is interpreted by the kernel
> incorrectly, and causes traffic flows above 9 to be
> classified into band 0 on multiband qdiscs.
> This changes the base
> I totally disagree with these POVs:
>
> - 10G cards should be treated by default as 10G cards - not
> DSL modems,
> and common users shouldn't have to read any warnings or configs to
> see this.
> - tc with TBF or HTB are professional tools; there should be
> added some
> warnings to man
> I've changed the -EIO into NETDEV_TX_BUSY and so far I can't
> trigger the bug anymore. It was quite easy to trigger within
> minutes with rsync, but I can't trigger it anymore. Should I
> send a patch, and if
> so: to who? The tulip/xircom_cb driver seems to be orphaned.
Perhaps Jeff Garzik
> Right - Essentially it is a usability issue:
> People who know how to use TSO (Peter for example) will be
> clueful enough to turn it on. Which means the default should
> be to protect the clueless and turn it off.
> On Andis approach:
> Turning TSO off at netdev registration time with a warnin
> Indeed. As an example of an unknowing user, this discussion
> made me check whether my cablemodem device (on which I'm
> using HFSC) uses TSO :)
The TSO defer logic is based on your congestion window and current
window size. So the actual frame sizes hitting your NIC attached to
your DSL prob
> ...But, on the other hand, in this case the realization seems to be
> wrong: probably still all locally created packets will be
> treated the same - or I miss something?
>
> Jarek P.
The TCP layer will generate TSO packets based on the kernel socket
features associated with the flow. So if yo
> Well, it could be just that when using such qdiscs TSO would be
> disabled, but the user could override this by using ethtool after
> loading the qdiscs.
I still disagree with this. The qdisc should not cause anything to happen to
feature flags on the device. It's the scheduling layer and real
> The philosophical problem I have with this suggestion is that
> I expect that the large majority of users will be more happy
> with disabled TSO if they use non standard qdiscs and
> defaults that do not fit the majority use case are bad.
>
> Basically you're suggesting that nearly everyone u
> My point was that without TSO different submitters will
> interleave their streams (because they compete about the
> qdisc submission) and then you end up with a smooth rate over
> time for all of them.
>
> If you submit in large chunks only (as TSO does) it will
> always be more bursty and
> Peter, I suspect that driver is just buggy in some other way
> as opposed to being re-entered; couldnt tell by inspection.
> It is possible it may be too eager to open up before it
> really has space.
> It will be easy to check your theory by having the driver
> just check if it is netif_stop
> > Are you using any specific qdisc, or just the default pfifo_fast?
> > Have you done any specific tuning on your qdisc as well?
> The default
> > qlen seems to have been changed.
>
> The driver seems buggy. Make it return NETDEV_TX_BUSY instead
> of -EIO in xircom_start_xmit() and the me
> I've just started to use 2.6.24 on my home firewall (before
> it was running 2.6.24-rc2 for about 65 days) and I noticed a
> couple of error messages I've never seen before:
>
> Jan 29 07:50:54 gateway kernel: BUG eth1 code -5 qlen 0 Jan
> 29 08:28:30 gateway kernel: BUG eth1 code -5 qlen 0 J
> 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?
Sorry for not respondin
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 07, 2007 3:52 AM
> To: Waskiewicz Jr, Peter P
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH] [AF_PACKET]: Allow multicast traffic to
> be caught by ORIGDEV
> > The socket option for packet sockets to return the original ifindex
> > instead of the bonded ifindex will not match multicast
> traffic. Since
> > this socket option is the most useful for layer 2 traffic and
> > multicast traffic, make the option multicast-aware.
> >
> > Signed-off-by:
> From: Rick Jones <[EMAIL PROTECTED]>
> Date: Thu, 11 Oct 2007 16:50:46 -0700
>
> > For just messing about, might it be possible to tweak the socket
> > buffer sizes and tcp_tso_win_divisor to kludge things for a short
> > while? Couldn't ship that way certainly, but assuming
> Peter's going
I'm having an issue with TSO right vs. hardware that can't take the
maximum segment size sent from the stack. I've been told that the
maximum packet size that can be sent to the hardware today is 64k, but
my hardware can only take 32k in certain modes per queue due to hardware
limitations. I have
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 10, 2007 9:02 AM
> To: Waskiewicz Jr, Peter P
> Cc: David Miller; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Wed, 10 Oct 2007 12:23:31 +0200
>
> > On Wed, Oct 10, 2007 at 02:25:50AM -0700, David Miller wrote:
> > > The chip I was working with at the time (UltraSPARC-IIi)
> compressed
> > > all the linear stores into 64-byte full cacheline
> transactions v
> A misunderstanding, I think.
>
> To my brain, DaveM's item #2 seemed to assume/require the NIC
> hardware to balance fairly across hw TX rings, which seemed
> to preclude the
> 8139cp/tg3 style of strict-prio hardware. That's what I was
> responding to.
>
> As long as there is some modular
> 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.
If I understand what you just said, I disagree. If your hardware is
running strict prio, you don't want to enfor
> If net_device_subqueue is visible from both driver and core
> scheduler area (couldnt tell from looking at whats in there
> already), then that'll do it.
Yes, I use the net_device_subqueue structs (the state variable in there)
in the prio and rr qdiscs right now. It's an indexed list at the
> 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.
That along with speeds going to 10 GbE with multiple Tx
> 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 enough packages (ive seen people use that terms to
> refer to packets) for each hardware ring's a
PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; netdev@vger.kernel.org;
> [EMAIL PROTECTED]; Waskiewicz Jr, Peter P;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTE
> > I really just need to put my nose to the grindstone and get the
> > patches together and to the list...stay tuned.
> >
> > Thanks,
> > -PJ Waskiewicz
> > -
>
>
> Since we are redoing this, is there any way to make the whole
> TX path more lockless? The existing model seems to be more
> o
> On Mon, 2007-24-09 at 15:57 -0700, Waskiewicz Jr, Peter P wrote:
>
> > I've looked at that as a candidate to use. The lock for
> enqueue would
> > be needed when actually placing the skb into the
> appropriate software
> > queue for the qdisc, so it'
> The one thing that seems obvious is to use
> dev->hard_prep_xmit() in the patches i posted to select the
> xmit ring. You should be able to do figure out the txmit ring
> without holding any lock.
I've looked at that as a candidate to use. The lock for enqueue would
be needed when actually
> I have submitted this before; but here it is again.
> Against net-2.6.24 from yesterday for this and all following patches.
>
>
> cheers,
> jamal
Hi Jamal,
I've been (slowly) working on resurrecting the original design
of my multiqueue patches to address this exact issue of the queue_
> Other pr_*() macros are already defined in kernel.h, but
> pr_err() was defined multiple times in several other places
>
> Signed-off-by: Emil Medve <[EMAIL PROTECTED]>
> ---
>
> I'm writing a driver and I've been using the pr_*() macros
> from kernel.h and I was surprised not to find there p
> From: Krishna Kumar2 <[EMAIL PROTECTED]>
> Date: Wed, 29 Aug 2007 10:43:23 +0530
>
> > The reason was to run parallel copies, not for buffer limitations.
>
> Oh, I see.
>
> I'll note in passing that current lmbench-3 has some
> parallelization features you could play with, you might want
> t
> Now if I insert a return -ENOMEM right after allocating tx_ring:
> --- a/drivers/net/e1000/e1000_main.c
> +++ b/drivers/net/e1000/e1000_main.c
> @@ -1356,6 +1356,8 @@ e1000_alloc_queues(struct e1000_adapter
> *adapter) {
> adapter->tx_ring = kcalloc(adapter->num_tx_queues,
>
> Index: linux-2.6/drivers/net/e1000/e1000_main.c
> ===
> --- linux-2.6.orig/drivers/net/e1000/e1000_main.c
> +++ linux-2.6/drivers/net/e1000/e1000_main.c
> @@ -860,15 +860,14 @@ e1000_probe(struct pci_dev *pdev, {
> struct net_
> * Waskiewicz Jr, Peter P <[EMAIL PROTECTED]>
> 2007-08-15 11:02
> > > There is this very horrible way of using the u32
> classifier with a
> > > negative offset to look into the ethernet header.
> >
> > Based on this, it sounds like u32 usin
> * Waskiewicz Jr, Peter P <[EMAIL PROTECTED]>
> 2007-08-09 18:07
> > My big question is: Has anyone recently used the 802_3
> protocol in tc
> > with u32 and actually gotten it to work? I can't see how the
> > u32_classify() code can look at th
I've recently been trying to use tc with u32 classifiers to filter
ethernet traffic based on ethertype. Although we found and fixed an
issue in the sch_prio call to tc_classify() (thanks Patrick!), this
didn't fix the actual filtering issue. For those of you who are curious
or are tc-savy, I'm re
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 30, 2007 5:14 PM
> To: Waskiewicz Jr, Peter P
> Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]
> Subject: Re: [FIX] NET: Fix sch_api and sch_prio to properly
> set and detect the
> On 7/26/07, David Miller <[EMAIL PROTECTED]> wrote:
> > From: Shannon Nelson <[EMAIL PROTECTED]>
> > Date: Tue, 24 Jul 2007 17:36:06 -0700
> >
> > > (repost - original eaten by vger?)
> > >
> > > Al Viro pointed out that dma_memcpy_to_kernel_iovec() really was
> > > unreachable and thus unused.
> From: Patrick McHardy [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 24, 2007 5:36 PM
> To: Waskiewicz Jr, Peter P
> Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org
> Subject: Re: [FIX] NET: Fix sch_api and sch_prio to properly
> set and detect the root qdisc
>
[...]
>
> This is the final fix for the problem Peter reported.
> Turns out most other schedulers get it right, the only other
> case is ingress setting skb->tc_index to the uninitialized
> value of res.classid.
I've applied this and tested prio and rr, and everything is happy again.
Thanks for finding
> In case of prio, if your manually installed filters don't
> match, it will fall back to the skb->priority based
> classification, which is based on tos and is probably
> responsible for what you're seeing. Feel free to investigate,
> but you could save us all some time by simply posting what
> Waskiewicz Jr, Peter P wrote:
> >>The protocol match is on skb->protocol, so it case of
> ethernet its on
> >>the ethernet protocol, which is ETH_P_IP or "ip" for IPv4.
> >
> >
> > I see that in the code, but the reason I started worryi
> The protocol match is on skb->protocol, so it case of
> ethernet its on the ethernet protocol, which is ETH_P_IP or
> "ip" for IPv4.
I see that in the code, but the reason I started worrying was when I
added the 802_3 classifier on 8 flows, it would shove all traffic into
flowid 1:1, no matte
I've been trying to use tc filtering to filter on ethertype, among other
things in the MAC layer. I'm running into multiple issues, and want to
put this out there in case I'm using the filters wrong, or if there
really is a bug in the filter code (I've stared at most of it today, and
my head hurts
> * netdev_pci_remove_one() can replace simple pci device remove
> functions
>
> * devm_alloc_netdev() is like alloc_netdev but allocates
> memory using devres.
> alloc_netdev() can be removed once all drivers use devres.
Please look at the multiqueue network code that is in 2.6.23. It
crea
> As explained in my last mail, sch->parent is an integer. And
> it is set when grafting the qdisc, not on initilization, so
> it is always 0 here when coming from prio_init.
>
> This untested patch should make sure its always set correctly.
Yes, I'm using NULL and 0 interchangeably here, sinc
> > Anyways, I tried a few different things, and what it looks like is
> > sch->parent will be NULL (0) for the top-level device. This is
> > sch->correct,
> > and trying to mess with that screws up qdisc_graft() when unloading
> > the qdisc. I also tried adding a TCQ_F_ROOT flag to
> sch->fla
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Sat, 21 Jul 2007 06:01:07 +0200
>
> > Waskiewicz Jr, Peter P wrote:
> > > I just sent out a patch to fix this.
> >
> > I didn't see it yet.
>
> VGER ate it for some reason and I didn't
> Its set after grafting the parent, which is after initialization.
> I think what should work is to set it in qdisc_create
> instead, sch_api.c around line 490:
>
> + sch->parent = handle;
>
> if (handle == TC_H_INGRESS) {
> sch->flags |= TCQ_F_INGRESS;
>
> Its set after grafting the parent, which is after initialization.
> I think what should work is to set it in qdisc_create
> instead, sch_api.c around line 490:
>
> + sch->parent = handle;
>
> if (handle == TC_H_INGRESS) {
> sch->flags |= TCQ_F_INGRESS;
>
> You're right, thats a bug. TC_H_ROOT is the parent ID, which
> is stored in sch->parent. IIRC its also passed to the
> ->init() function.
Unfortunately it's not passed. It is passed into the ->change()
function:
static int prio_init(struct Qdisc *sch, struct rtattr *opt)
static int prio_ch
I've been tracking down an issue with the recent multiqueue code,
specifically with sch_prio and sch_rr loading as a root qdisc. Right
now, we do not want to allow child qdiscs of sch_rr and sch_prio to load
with multiqueue enabled; we want to restrict multiqueue-enabled qdiscs
to the root qdisc (
> It would be great if we could finally get a working e1000
> multiqueue patch so work in this area can actually be tested.
I'm actively working on this right now. I'm on vacation next week, but
hopefully I can get something working before I leave OLS and post it.
-PJ
-
To unsubscribe from this
> Ok everything is checked into net-2.6.23, thanks everyone.
Dave, thank you for your patience and feedback on this whole process.
Patrick and everyone else, thank you for your feedback and assistance.
I am looking at your posed virtualization question, but I need sleep
since I just remembered I'
> Waskiewicz Jr, Peter P wrote:
> >>
> >> Looking at Peter's multiqueue patch, which should include all
> >> hard_start_xmit users (I'm not seeing sch_teql though,
> >> Peter?) the only other one is pktgen.
> >>
>
> -Original Message-
> From: Patrick McHardy [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 28, 2007 12:37 PM
> To: Jeff Garzik
> Cc: Waskiewicz Jr, Peter P; [EMAIL PROTECTED];
> netdev@vger.kernel.org; Kok, Auke-jan H; [EMAIL PROTECTED]
> Subject: Re: [PATCH 2
> Waskiewicz Jr, Peter P wrote:
> >>[...]
> >>The only reasonable thing it can do is not care about
> multiqueue and
> >>just dequeue as usual. In fact I think it should be an error to
> >>configure multiqueue on a non-root qdisc.
> >
> >
> Absolutely not. First of all, its perfectly valid to use
> non-multiqueue qdiscs on multiqueue devices. Secondly, its
> only the root qdisc that has to know about multiqueue since
> that one controls the child qdiscs.
>
> Think about it, it makes absolutely no sense to have the
> child qdisc
> Waskiewicz Jr, Peter P wrote:
> >>Quick question: where are the sch_generic changes? :)
> >>
> >>If you hold for ten minutes I'll post a set of slightly changed
> >>patches with the NETDEVICES_MULTIQUEUE option and a fix for this.
> >
> >
> PJ Waskiewicz wrote:
> > +#ifdef CONFIG_NET_SCH_MULTIQUEUE
> > + if (q->mq)
> > + skb->queue_mapping =
> > +
> q->prio2band[band&TC_PRIO_MAX];
> > + else
> > + skb->
> PJ Waskiewicz wrote:
> > include/linux/etherdevice.h |3 +-
> > include/linux/netdevice.h | 62
> ++-
> > include/linux/skbuff.h |4 ++-
> > net/core/dev.c | 27 +--
> > net/core/netpoll.c |8 ++
> Its not error handling. You do:
>
> err = register qdisc 1
> if (err)
> return err;
> err = register qdisc 2
> if (err)
> unregister qdisc 2
> return err
>
> anyways, I already fixed that and cleaned up prio_classify
> the way I suggested. Will send shortly.
Thanks for fixing; ho
> Since rr is not built as a module you could actually put
> everything in q_prio and share the code. But I don't really care :)
I tried doing this, but I couldn't get things working quite right with
selecting the correct module from sch_prio to sch_rr. So I just added
the q_rr.c portion of tc,
> PJ Waskiewicz wrote:
>
> > +
> > static int __init prio_module_init(void) {
> > - return register_qdisc(&prio_qdisc_ops);
> > + int err;
> > + err = register_qdisc(&prio_qdisc_ops);
> > + if (!err)
> > + err = register_qdisc(&rr_qdisc_ops);
> > + return err;
> > }
> >
>
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Mon, 25 Jun 2007 23:08:09 +0200
>
> > David Miller wrote:
> > >
> > >> I've been using this patch and the IPROUTE2 patches Patrick has
> > >> proposed with no issues. Can someone else look at these patches
> > >> when they have time? I'd be i
> Thats not necessary. I just though you could add one exit point:
>
>
> ...
> out:
> skb->queue_mapping = q->mq ? band : 0;
> return q->queues[band];
> }
>
> But if that doesn't work don't bother ..
Unfortunately it won't, given how band might be used like this to select
the queue:
re
> > @@ -70,14 +72,28 @@ prio_classify(struct sk_buff *skb, struct Qdisc
> > *sch, int *qerr) #endif
> > if (TC_H_MAJ(band))
> > band = 0;
> > + if (q->mq)
> > + skb->queue_mapping =
> > +
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 25, 2007 2:30 PM
> To: Waskiewicz Jr, Peter P
> Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org;
> [EMAIL PROTECTED]
> Subject: Re: [RTNETLINK]: Add nested compat attribute
>
> From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
> Date: Mon, 25 Jun 2007 10:14:37 -0700
>
> > > This patch adds a new attribute type that can be used to replace
> > > non-nested attributes that contain structures by nested ones in a
> > &
> PJ Waskiewicz wrote:
> > + /* If we're multiqueue, make sure the number of incoming bands
> > +* matches the number of queues on the device we're
> associating with.
> > +*/
> > + if (tb[TCA_PRIO_MQ - 1])
> > + q->mq = *(unsigned char *)RTA_DATA(tb[TCA_PRIO_MQ - 1]);
> > +
> > enum
> > {
> > - TCA_PRIO_UNPSEC,
> > - TCA_PRIO_TEST,
>
>
> You misunderstood me. You can work on top of my compat
> attribute patches, but the example code should not have to go
> in to apply your patch.
Ok. I'll fix my patches.
> > diff --git a/net/sched/Kconfig b/net/sched/Kcon
> This patch adds a new attribute type that can be used to
> replace non-nested attributes that contain structures by
> nested ones in a compatible way.
>
> This can be used in cases like Peter's who is trying to
> extend sch_prio, which currently uses a fixed structure
> without any holes.
>
> > /* ensure 32-byte alignment of both the device and
> private area */
> > - alloc_size = (sizeof(*dev) + NETDEV_ALIGN_CONST) &
> ~NETDEV_ALIGN_CONST;
> > + alloc_size = (sizeof(*dev) + NETDEV_ALIGN_CONST +
> > +(sizeof(struct net_device_subqueue) *
> (queue_count - 1))
> Patrick McHardy wrote:
> > Waskiewicz Jr, Peter P wrote:
> >
> >>Thought about this more last night and this morning. As
> far as I can
> >>tell, I still need this. If the qdisc gets loaded with multiqueue
> >>turned on, I can just use the v
> > #include
> > @@ -40,9 +42,13 @@
> > struct prio_sched_data
> > {
> > int bands;
> > +#ifdef CONFIG_NET_SCH_RR
> > + int curband; /* for round-robin */
> > +#endif
> > struct tcf_proto *filter_list;
> > u8 prio2band[TC_PRIO_MAX+1];
> > struct Qdisc *queues[TCQ_PRIO_BANDS];
> The dependencies seem to be very confused. SCHED_PRIO does
> not depend on anything new, SCH_RR also doesn't depend on
> anything. SCH_PRIO_MQ and SCH_RR_MQ (which is missing) depend
> on SCH_PRIO/SCH_RR. A single NET_SCH_MULTIQUEUE option seems
> better than adding one per scheduler though.
> PJ Waskiewicz wrote:
> > I did not modify other users of netif_queue_stopped() in
> > net/core/netpoll.c, net/core/dev.c, or net/core/pktgen.c, since no
> > classification occurs for the skb being sent to the device.
> > Therefore, packets should always be ending up in queue 0,
> so there's
> > Yes. This is the tc command I used to configure the qdisc (with
> > q_rr.c attached from my patches iproute2 package):
> >
> > # tc qdisc add dev eth2 root handle 1: rr bands 8 RTNETLINK
> answers:
> > No such file or directory
>
> Again, I bet you don't have CONFIG_NET_SCH_RR enabled:
Ch
> Waskiewicz Jr, Peter P wrote:
> >> Please post the code.
> >>
> >>
> >
> > Code is attached. Please forgive the attachment and any whitespace
> > damage...currently using Doubtlook to send this (cringe).
> >
>
> The code look
> Please post the code.
>
Code is attached. Please forgive the attachment and any whitespace
damage...currently using Doubtlook to send this (cringe).
Thanks,
-PJ Waskiewicz
sch_prio.c
Description: sch_prio.c
> BTw, couldn't you just merge sch_rr with prio? AFAICT you
> only need a new dequeue function, a new struct Qdisc_ops and
> a MODULE_ALIAS.
Ok, I have this somewhat working, but need to poll for some help from
the community. I used MODULE_ALIAS("sch_rr") in sch_prio.c, and
modprobe is happily
> to me it seems that this patch set only include multiple
> transmit queue support (for qdisc). Am I right with this
> observation? If so, are there also plans to support multiple
> receive queues to allow the queues to be processed in
> parallel on different CPUs via a standard interface?
>
> It's not being allocated at "compile time", it's being
> allocated linearly into one block of ram in order to avoid
> pointer derefs but it's still "dynamic" in that the size
> isn't known until the alloc_netdev() call.
>
> We do this trick all over the networking, TCP sockets are 3
> or 4 d
> From: PJ Waskiewicz <[EMAIL PROTECTED]>
> Date: Mon, 18 Jun 2007 11:42:29 -0700
>
> > +
> > + /* The TX queue control structures */
> > + struct net_device_subqueue *egress_subqueue;
> > + int egress_subqueue_count;
>
> Since every net device will have at
> From: PJ Waskiewicz <[EMAIL PROTECTED]>
> Date: Mon, 18 Jun 2007 11:42:29 -0700
>
> > +
> > + /* The TX queue control structures */
> > + struct net_device_subqueue *egress_subqueue;
> > + int egress_subqueue_count;
>
> Since every net device will have at
1 - 100 of 158 matches
Mail list logo
