Full quote below. So what is the consensus on this topic?
I read the emails but i dont see a resolution.
cheers,
jamal
On 06/03/15 08:08, Jamal Hadi Salim wrote:
On 06/02/15 10:30, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 4:43 AM, Jamal Hadi Salim j...@mojatatu.com
wrote:
On 06/02/15 03
undo most of the earlier workaround commit:
a166151cbe33 (bpf: fix bpf helpers to use skb-mac_header relative offsets)
Signed-off-by: Alexei Starovoitov a...@plumgrid.com
---
Acked-by: Jamal Hadi Salim j...@mojatatu.com
cheers,
jamal
--
To unsubscribe from this list: send the line unsubscribe
On 06/02/15 10:30, Scott Feldman wrote:
On Tue, Jun 2, 2015 at 4:43 AM, Jamal Hadi Salim j...@mojatatu.com wrote:
On 06/02/15 03:10, Scott Feldman wrote:
Question to ask when looking at something of this nature:
Will it work with no suprises if you used today's unmodified app?
The default
On 06/02/15 03:10, Scott Feldman wrote:
Actually, we're now consistent with bridge man page which says master
is the default.
Want we want, I believe, is to adjust what the man page says (and the
bridge vlan command itself), by making the default master and self.
The kernel and driver are
On 05/22/15 13:33, Nicholas Krause wrote:
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index ad9eed7..44a8995 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -400,7 +400,7 @@ struct qdisc_rate_table *qdisc_get_rtab(struct tc_ratespec
*r, struct nlattr *ta
}
On 05/26/15 05:31, Jamal Hadi Salim wrote:
On 05/22/15 13:33, Nicholas Krause wrote:
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index ad9eed7..44a8995 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -400,7 +400,7 @@ struct qdisc_rate_table *qdisc_get_rtab(struct
On 05/21/15 14:58, Uwe Kleine-König wrote:
Hello,
My picture of the network stack might be wrong, but if the ethernet
driver queues say 5 packets to the network stack and the fourth is a MRP
packet than a priorization that makes the fourth packet processed first
would be nice.
If there is
On 05/21/15 03:07, Uwe Kleine-König wrote:
On Wed, May 20, 2015 at 05:30:40PM -0700, Eric Dumazet wrote:
On Wed, 2015-05-20 at 16:46 -0700, Cong Wang wrote:
There is very little to do on ingress side since there is no queue at all,
not to mention priority, you could try ifb to see if it fits
On 05/20/15 20:26, Florian Westphal wrote:
Jamal points out that this header also contains kernel internal magic that
cannot be used from userspace for anything meaningful.
Lets remove what the kernel doesn't use anymore and wrap remainder with
__KERNEL__.
Suggested-by: Jamal Hadi Salim j
.
As the culprit who added this lock I would like to offer a kudos
to John for the hard work. Alexei thanks for the hard work in
pursuing this further.
And to the rest of the community who has been beating up on me
all these years, you can stop now ;-
I think this at least deserves a:
Signed-off-by: Jamal Hadi
On 04/30/15 17:16, Alexei Starovoitov wrote:
On Thu, Apr 30, 2015 at 12:12:00PM +0200, Florian Westphal wrote:
Not used.
pedit sets TC_MUNGED when packet content was altered, but all the core
does is unset MUNGED again and then set OK2MUNGE.
And the latter isn't tested anywhere. So lets
On 04/23/15 20:59, Alexei Starovoitov wrote:
On 4/23/15 3:51 PM, Jamal Hadi Salim wrote:
So you are planning to add queues? If you are that is a different
discussion (and the use case needs some clarity).
nope. I wasn't planning to do that.
Then i would say, lets just keep the naming
On 04/23/15 18:13, Alexei Starovoitov wrote:
On 4/23/15 1:45 PM, Jamal Hadi Salim wrote:
then it is worse mess than I thought :(
Why call it _qdisc_ then? and have special and convoluted handling for
it in qdisc_create, qdisc_graft and other places?
Convinience for tooling and using
On Mon, 2006-07-08 at 17:59 +0200, Edgar E. Iglesias wrote:
Ok, I thought you wanted the code inside the ifdefs to be considered. If not,
I guess there is no problem. Yes, the forwarding case does not suffer from
any deadlocks issues that I am aware of.
From my tests:
It does _not_ provide
On Tue, 2006-01-08 at 17:45 +1000, Herbert Xu wrote:
On Tue, Aug 01, 2006 at 12:36:14AM -0700, David Miller wrote:
- tc_verd/tc_index/input_dev: when directing a packet from a device
supporting GSO to a device not supporting GSO using tc actions,
these fields may be set.
On Tue, 2006-01-08 at 16:03 +0400, a1 wrote:
I thought the common behavior is that if one side force any particular
parameter, other side should sense that and go to that mode too.
You _cannot_ depend on that behavior at all. IOW, if one side is not
forced the other side's setting is
On Tue, 2006-01-08 at 08:08 -0400, John W. Linville wrote:
[..]
There is no doubt that we need to be able to do all three (vlan,
bridge, bond) at once. I'm just not convinced we need to support
stacking them in every conceivable order.
In theory there should be no issues stacking netdevices
On Tue, 2006-01-08 at 22:34 +1000, Herbert Xu wrote:
What I'd like to know is do we really need to preserve
tc_verd/tc_index/input_dev
for a packet crossing loopback's xmit function?
My instinctive reaction is to say no. Heres a (slightly complex)
example:
-- eth0(GSO ON) --- lo
On Mon, 2006-31-07 at 17:49 -0700, Roland Dreier wrote:
David Why is this a relevant analogy? Well, you have physical
David hard-disks in your computer today, but at some point that
David device becomes largely superfluous. It makes more sense to
David have just a cpu with a
On Mon, 2006-31-07 at 08:30 -0400, John W. Linville wrote:
On Mon, Jul 31, 2006 at 10:15:40AM +0200, Christophe Devriese wrote:
If you bond 2 vlan subinterfaces, the patch is not necessary at all. In
that
case also the source device will be changed from eth0.vlan to bondx. So
that's
On Tue, 2006-01-08 at 11:30 +1000, Herbert Xu wrote:
You can now disable the OOM killer on a per-process basis by
echo -17 /proc/pid/oom_adj
nice to know ;- At least you can protect some apps if you need to.
Only racoon and quagga are important for me.
But what happens then if you have
On Thu, 2006-22-06 at 18:49 -0400, [EMAIL PROTECTED] wrote:
plain text document attachment (netlabel-cipsov4)
Add CIPSO/IPv4 support and management to the NetLabel subsystem. These
changes
integrate the CIPSO/IPv4 configuration into the existing NetLabel code and
enable the use of
On Fri, 2006-28-07 at 13:15 +0200, Lennert Buytenhek wrote:
On Fri, Jul 28, 2006 at 12:49:46PM +0200, Francois Romieu wrote:
The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work
initially, but they don't actually seem to transmit any packets on the
wire, nor do they
On Fri, 2006-28-07 at 09:34 +0100, Hugo Santos wrote:
2. What if user process dies? or gets overwhelmed?
One of the assumptions of the any well designed kernel is that the
system should never
hang because some user application died or waited for ever.
Of course that this is a
by
Andy Furniss [EMAIL PROTECTED]
Also make it a little more readable.
---
commit e2e0fac73a39bc6878f93cd7698f4c823ef85546
tree cfdad9a98fa1925237128b307d8ddd77b86a09a7
parent a067bda2c7c9972ad77ac174830a245896d18897
author Jamal Hadi Salim [EMAIL PROTECTED] Wed, 26 Jul 2006 07:45:25 -0400
committer
On Thu, 2006-13-07 at 10:50 -0700, Randy.Dunlap wrote:
On Mon, 19 Jun 2006 09:41:22 -0400 jamal wrote:
Folks,
Attached is a document that should help people wishing to use generic
netlink interface. It is a WIP so a lot more to go if i see interest.
Hi,
I have a few random
On Fri, 2006-14-07 at 12:03 -0700, Stephen Hemminger wrote:
The upper bound for HTB time diff needs to be scaled to PSCHED
units rather than just assuming usecs. The field mbuffer is used
in TDIFF_SAFE(), as an upper bound. Untested...
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
On Tue, 2006-11-07 at 16:57 -0700, Randy.Dunlap wrote:
so make it a patch to Documentation/networking/...
I was going to when it got in better shape. Good suggestion, I will do
this soon and put it there as a patch.
I have some doc corrections, Jamal. Do I send them against
the
On Sun, 2006-09-07 at 08:52 -0400, Jamal Hadi Salim wrote:
Ok, didnt complete my thought there ..
I dont like it, like i said, because it adds one more check
in the first path. I was contemplating at some point even not doing the
.. not doing the check for device up and just shove
On Sun, 2006-09-07 at 15:33 +0200, Thomas Graf wrote:
* Jamal Hadi Salim [EMAIL PROTECTED] 2006-07-09 08:52
[..]
Another simpler approach is to check for recursion right in
It's very interesting that you change from there is no easy way
to another simpler approach... in just one posting
On Sun, 2006-09-07 at 16:19 +0200, Thomas Graf wrote:
* Jamal Hadi Salim [EMAIL PROTECTED] 2006-07-09 10:03
On Sun, 2006-09-07 at 15:33 +0200, Thomas Graf wrote:
That's not gonna work, dev-queue_lock may be held legimitately
by someone else than an underlying dev_queue_xmit() call
On Sat, 2006-08-07 at 10:14 -0400, Jamal Hadi Salim wrote:
I have a dated patch to mirred (may not apply cleanly)
Sorry forgot to attach the patch. Attached for real this time;-
that i believe
will fix this specific one. Try to see if it also fixes this case you
have.
I meant i know
On Fri, 2006-23-06 at 13:35 +1000, Herbert Xu wrote:
On Thu, Jun 22, 2006 at 08:52:17PM -0400, jamal wrote:
It does feel like the qdisc_is_running though is now a replacement
for the need for dev-txlock which existed to protect multi-cpus from
entering the device transmit path. Is that
Sorry, Unintentionaly trimmed Dave and netdev
Forwarded Message
From: jamal [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Patrick McHardy [EMAIL PROTECTED]
Subject: Re: [PKT_SCHED 00/05]: net/sched patches for 2.6.17
Date: Fri, 17 Feb 2006 10:05:38 -0500
On Fri, 2006-17-02
-off-by: Per Liden [EMAIL PROTECTED]
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
BTW, thinking in the background we may in the future need the owner
field for users of those modules (not for gennetlink to increment) but
lets worry about that in the future.
cheers,
jamal
-
To unsubscribe
We've had this discussion before, Patrick;-
Heres one i was able to find:
http://marc.theaimsgroup.com/?t=11061115951r=1w=2
So NACK this spefic patch please.
cheers,
jamal
PS:- Please CC me on stuff like this so it doesnt get buried by my
filters for congestion control reasoning.
-
To
On Sun, 2006-08-01 at 18:10 +0100, Patrick McHardy wrote:
[..]
That discussion had nothing to do with this patch, you actually
already agreed to doing this. Passing double skb pointers is broken:
int tcf_action_exec(struct sk_buff *skb, struct tc_action *act,
struct
traffic for shaping instead of
dropping.
Packets are redirected to this device using tc/action mirred redirect
construct. If they are sent to it by plain routing instead
then they will merely be dropped and the stats would indicate that.
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
---
diff
On Sun, 2006-08-01 at 18:46 +0100, Patrick McHardy wrote:
[..]
int tcf_action_exec(struct sk_buff *skb, struct tc_action *act,
struct tcf_result *res)
{
...
ret = a-ops-act(skb, a, res);
The caller later continues to use the skb passed to
as not to confuse TCP
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
---
diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
index 09453f9..c962070 100644
--- a/net/sched/sch_cbq.c
+++ b/net/sched/sch_cbq.c
@@ -257,7 +257,7 @@ cbq_classify(struct sk_buff *skb, struct
(cl = cbq_class_lookup(q
On Sun, 2006-08-01 at 19:32 +0100, Patrick McHardy wrote:
Jamal Hadi Salim wrote:
It seems to be a big
change at glance and normally i would like to run some serious tests
on something like this (this one you can actually test with a series of
mirred, pedit and gact while tcpdump
On Sun, 2006-08-01 at 19:35 +0100, Patrick McHardy wrote:
Jamal Hadi Salim wrote:
[..]
if (cl == NULL) {
- if (ret == NET_XMIT_DROP)
+ if (ret == NET_XMIT_DROP || ret == NET_XMIT_BYPASS)
No objections to the new mapping, but the NET_XMIT_DROP handling
here
Ok, heres a resubmit after discussion with Patrick.
cheers,
jamal
The mapping between TC_ACTION_SHOT and the qdisc return codes is better
suited to NET_XMIT_BYPASS so as not to confuse TCP
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
---
diff --git a/net/sched/sch_cbq.c b/net/sched
On Sun, 2006-08-01 at 20:34 +0100, Patrick McHardy wrote:
Jamal Hadi Salim wrote:
Maybe no need to worry about both situations for now, i will resubmit
the patch without worrying about NET_XMIT_DROP.
Looking at it again, I think you should not change the existing return
code but just use
On Fri, 2005-11-11 at 21:33 +0100, Krzysztof Halasa wrote:
jamal [EMAIL PROTECTED] writes:
well, the kernel doesnt add default routes - some admin or daemon does.
So whatever solution it is should not delete such routes either.
Sure. Inactivate them instead and activate back on carrier
On Thu, 2005-10-11 at 01:10 +0100, Thomas Graf wrote:
* Jamal Hadi Salim [EMAIL PROTECTED] 2005-11-09 18:49
Historically we point such routes to the dummy device. Remember diald
and good ole SLIP dial on demand? I would suspect it should still work
the same way.
Actually, probably use
On Thu, 2005-10-11 at 14:17 +0100, Krzysztof Halasa wrote:
Stefan Rompf [EMAIL PROTECTED] writes:
ACK. We really should not be forced to modify all ethernet drivers in
order to
allow userspace changing dormant for 802.1X and friends.
ACK too. In fact we are at all unable to modify
On Thu, 2005-10-11 at 02:25 +0100, Thomas Graf wrote:
plain text document attachment (nl_generic)
The generic netlink family builds on top of netlink and provides
simplifies access for the less demanding netlink users. It solves
the problem of protocol numbers running out by introducing a so
Folks,
I just scanned really quickly so maybe missing things ..
I will try and list the contended issues and my comments below. Again, I
may have missed something since it was a quick scan.
1) In regards to the connected routes:
- I would agree that there is need to do something about them -
On Wed, 2005-09-11 at 22:02 +0100, Stefan Rompf wrote:
Am Mittwoch 09 November 2005 21:13 schrieb Jamal Hadi Salim:
1) In regards to the connected routes:
- I would agree that there is need to do something about them - but i
dont think those extra L3* states are the answer. So Stefan, we
On Wed, 2005-09-11 at 22:12 +0100, Thomas Graf wrote:
* Jamal Hadi Salim [EMAIL PROTECTED] 2005-11-09 15:13
The link change notification should be handled by the fib code as if it
was an admin notification.
Something like this should do the job, although it doesn't take care
of taking
On Thu, 2005-10-11 at 00:38 +0100, Krzysztof Halasa wrote:
Stefan Rompf [EMAIL PROTECTED] writes:
I think it is valid to define the operational state as one field simply
due to
the fact that the driver is solely responsible for it.
That would be nice but isn't the case. With my WAN
Sorry, I read my emails in a LIFO manner - typically that works well
with last email in thread covering all the previous, but occasionally
something is left over.
On Sat, 2005-23-07 at 18:14 +0200, Thomas Graf wrote:
i.e you map the time slots to weights and priorities on the rings to the
On Sun, 2005-24-07 at 23:18 -0400, Jamal Hadi Salim wrote:
Posting a bunch of patches that explicitly set input_dev to dev
right before netif_rx() sort of further proves my point :-)
;-
Let me sleep it over and think about it - I am not thinking straight
right now. I am back home, so
On Mon, 2005-25-07 at 03:31 +0200, Thomas Graf wrote:
Anyways, tc_verd needs a serious cleanup, not just for the
macros which we might want to replace with bitfields or
at least have generic macros to generate the masks.
Right - and as we discussed:
- recall that the use of bit operations is
On Sun, 2005-24-07 at 19:02 -0700, David S. Miller wrote:
I agree they will mean the same thing.
The example i gave was to show where one meaning contradicts the other.
And the current specific settings of input_dev has the following
problems:
1) you cannot ingress classify on tunneling
Did you check if there was no side effect with the macros that
manipulate tc_verdict?
cheers,
jamal
On Sat, 2005-23-07 at 07:03 +0200, Patrick McHardy wrote:
plain text document attachment (x)
[NET]: Reduce tc_index/tc_verd to u16
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
On Fri, 2005-22-07 at 15:52 -0700, David S. Miller wrote:
Sounds OK. What happens if the top-level queue pulls out
a packet with a certain priority, and that priority's queue
in the device is stopped? Will it look for lower-priority
packets and try to send those? All of this kind of logic
On Sat, 2005-23-07 at 16:29 +0200, Thomas Graf wrote:
I think we should head for a 16bit ifindex at some point
or is there any reason why 65K interfaces wouldn't be
sufficient? We waste one bit at the moment to have simpler
error handling for all the functions returning indices.
Strange, i
On Sat, 2005-23-07 at 16:50 +0200, Thomas Graf wrote:
No, we use s32 at the moment with the limitation that negative indices
are illegal. We don't have to break the interfaces just because of this,
but since dev_new_ifindex() will be reusing gone indices if needed it
might be possible to at
1001 - 1060 of 1060 matches
Mail list logo
