On Mon, Nov 28, 2022 at 3:56 AM Tianyu Yuan wrote:
>
> Hi Jamal,
>
>
> When no action is specified, there should not be gact with PIPE, rather than
> a gact with drop, like:
>
Thanks for the example dumps. I think you should put them in your commit logs.
[..]
>
> About the second scenario of
Hi Tianyu,
On Thu, Nov 24, 2022 at 10:10 PM Tianyu Yuan
wrote:
> On Fri, Nov 25, 2022 at 10:21 AM Jamal Hadi Salim
> wrote:
>
> >
> > I am not sure if the mlx5 changes will work since they both seem to be
> calling
> > mlx5e_tc_act_get() which expects the a
I am not sure if the mlx5 changes will work since they both seem to be calling
mlx5e_tc_act_get() which expects the act->id to exist in tc_acts_xxx tables,
meaning mlx5e_tc_act_get() will always return you NULL and that check
is hit before you check for ACT_PIPE.
Something not obvious to me:
On Fri, Oct 14, 2022 at 9:00 AM Ilya Maximets wrote:
>
[..]
> > I thought it was pipe but maybe it is OK(in my opinion that is a bad code
> > for just "count"). We have some (at least NIC) hardware folks on the list.
>
> IIRC, 'OK' action will stop the processing for the packet, so it can
> only
On Fri, Oct 7, 2022 at 1:37 PM Marcelo Leitner wrote:
>
> On Fri, Oct 07, 2022 at 11:59:42AM -0400, Jamal Hadi Salim wrote:
> > On Fri, Oct 7, 2022 at 11:01 AM Marcelo Leitner wrote:
> > >
[..]
> >
> > It's mostly how people who offload (not sure a
On Fri, Oct 7, 2022 at 11:01 AM Marcelo Leitner wrote:
>
> On Fri, Oct 07, 2022 at 04:39:25PM +0200, Davide Caratti wrote:
> > On Fri, Oct 7, 2022 at 3:21 PM Marcelo Leitner wrote:
> > >
> > > (+TC folks and netdev@)
> > >
> > > On Fri, Oct 07, 2022 at 02:42:56PM +0200, Ilya Maximets wrote:
> >
the static key which is used by openvswitch module to
guard this code path as well, so it will be skipped if ovs
datapath doesn't need it. Enable this code path once
ovs datapath needs it.
Signed-off-by: Paul Blakey
For the tc bits:
Reviewed-by: Jamal Hadi Salim
cheers,
jamal
On 2022-02-01 12:52, Paul Blakey wrote:
Tc skb extension is used to send miss info from tc to ovs datapath
module, and is currently always allocated even if it will not
be used by ovs datapath (as it depends on a requested feature).
Export the static key which is used by openvswitch module to
this, by flagging to openvswitch which NAT was actually done in
act_ct via tc_skb_ext and tc_skb_cb to the openvswitch module, so
the packet flow key NAT flags will be correctly set.
Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct")
Signed-off-by: Paul Blakey
Acked-by: Jamal Hadi Salim
che
On 2022-01-05 11:18, Paul Blakey wrote:
On Wed, 5 Jan 2022, Daniel Borkmann wrote:
[..]
Full ack on the bloat for corner cases like ovs offload, especially
given distros just enable most stuff anyway and therefore no light
fast path as with !CONFIG_NET_TC_SKB_EXT. :(
Could this somehow
On 2022-01-04 03:28, Paul Blakey wrote:
[..]
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -287,7 +287,9 @@ struct tc_skb_ext {
__u32 chain;
__u16 mru;
__u16 zone;
- bool post_ct;
+ bool post_ct:1;
+ bool post_ct_snat:1;
+ bool
On 17-04-16 10:45 AM, David Ahern wrote:
On 4/16/17 8:40 AM, Jamal Hadi Salim wrote:
Johannes or anybody else working on it?
i.e one which sends the extack to the bowels of callees
so we can return meaningful messages
example: rtnetlink::doit() or equivalent seems to be a candidate for
taking
Johannes or anybody else working on it?
i.e one which sends the extack to the bowels of callees
so we can return meaningful messages
example: rtnetlink::doit() or equivalent seems to be a candidate for
taking it as a param
For things that call netlink_ack it may be easier if they create
the
On 03/05/15 02:39, John Fastabend wrote:
The intent was to reserve space in the tables for l2, l3, user space,
and whatever else is needed. This reservation needs to come from the
administrator because even the kernel doesn't know how much of my
table space I want to reserve for l2 vs l3 vs tc
On 03/05/15 07:37, Jamal Hadi Salim wrote:
On 03/05/15 02:39, John Fastabend wrote:
Would kernel boot/module options passed to the driver not suffice?
That implies a central authority that decides what these table size
slicing looks like.
Once the reservation of resources occurs we wouldn't
On 09/22/14 21:36, John Fastabend wrote:
n-tuple has some deficiencies,
- its not possible to get the capabilities to learn what
fields are supported by the device, what actions, etc.
- its ioctl based so we have to poll the device
- only supports a single table, where
On 09/22/14 03:53, Jiri Pirko wrote:
Jamal, would you please give us some examples on how to use tc to work
with flows? I have a feeling that you see something other people does not.
I will be a little verbose so as to avoid knowledge assumption.
Lets talk about tc classifier/action
On 09/20/14 04:17, Jiri Pirko wrote:
Yes, that I say. It is needed for flow manipulation, because such api does
not exist.
Come on Jiri!
The ovs guys are against this and now no *api exists*?
Write a 15 tuple classifier tc classifier and use it. I will be more
than happy to help you. I will
On 09/20/14 04:10, Scott Feldman wrote:
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu ro...@cumulusnetworks.com wrote:
Existing rtnetlink isn’t available to swdev without some kind of snooping the
echoes from the various kernel components
(bridge, fib, etc).
You have made this claim before
On 09/20/14 07:01, Thomas Graf wrote:
Nothing speaks against having such a tc classifier. In fact, having
the interface consist of only an embedded Netlink attribute structure
would allow for such a classifier in a very straight forward way.
That doesn't mean everybody should be forced to use
On 09/20/14 07:51, Thomas Graf wrote:
I fail to see the connection. You can use switch vendor SDK no matter
how we define the kernel APIs. They already exist and have been
designed in a way to be completely indepenedent from the kernel.
Are you referring to vendor specific decisions in user
On 09/19/14 09:49, Jiri Pirko wrote:
This patch exposes switchdev API using generic Netlink.
Example userspace utility is here:
https://github.com/jpirko/switchdev
Is this just a temporary test tool? Otherwise i dont see reason
for its existence (or the API that it feeds on).
cheers,
jamal
On 09/19/14 11:49, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
Is this just a temporary test tool? Otherwise i dont see reason
for its existence (or the API that it feeds on).
Please read the conversation I had with Pravin and Jesse in v1 thread.
Long
On 09/19/14 18:12, John Fastabend wrote:
On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
On 09/19/14 11:49, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
Is this just a temporary test tool? Otherwise i dont see reason
for its existence (or the API
On 09/05/14 03:02, Scott Feldman wrote:
On Thu, Sep 04, 2014 at 09:30:45AM -0700, Scott Feldman wrote:
Correct, for the particular switch implementation we’re working with.
Do you have L2/3 working with this interface on said switch?
I am interested.
cheers,
jamal
On 09/03/14 17:59, Pravin Shelar wrote:
Both of us are saying same thing.
What I meant was for OVS use-case, where OVS wants to use offload for
switching flows, vswitchd userspace process can program HW offload
using kernel HW offload APIs directly from userspace, rather than
going through OVS
On 09/01/14 04:13, Simon Horman wrote:
On Fri, Aug 29, 2014 at 10:20:55AM -0400, Jamal Hadi Salim wrote:
I actually have no issues with whatever classifier someone decides
to use. To each their poison. But I do take issue mandating the
specified classifer it as THE CLASSIFIER as in this case
On 08/26/14 16:54, Thomas Graf wrote:
On 08/26/14 at 01:13pm, Alexei Starovoitov wrote:
I think it's important distinction. In-kernel OVS is not OF.
It's a networking function that has hard-coded packet parser,
N-tuple match and programmable actions.
There were times when HW vendors were using
? And if the answer is negative
they simply dont show up;-
On 08/25/14 at 12:48pm, Jamal Hadi Salim wrote:
On 08/25/14 10:54, Thomas Graf wrote:
I would argue that swflow is a superset of a Netlink route. It
may infact be very useful to extend the API with something that
understands the Netlink representation
On 08/25/14 18:50, Thomas Graf wrote:
On 08/25/14 at 12:15pm, Jamal Hadi Salim wrote:
On 08/25/14 10:17, Thomas Graf wrote:
I dont think we have a problem handling any of this today.
Yes we do. It's restricted to L2 and we can't extend it easily
It is restricted to L2 because it is L2
On 08/26/14 10:06, Jiri Pirko wrote:
Yes. Flows are phase one. The api will be extended in for whatever is
needed for l2/l3 as you said. Also I see a possibility to implement the
l2/l3 use case with flows as well.
And as a note: This is where i have the disagreement.
It is good there is
On 08/26/14 11:01, Scott Feldman wrote:
I don’t see it that way. I believe sw_flow can be the intermediary
representation to span flow-based and non-flow-based HW,
and from flow-based world and traditional l2/l3 world.
Is there more magic to this than what Thomas just presented in
On 08/26/14 11:22, Jiri Pirko wrote:
I do not think that really matters. Phase one is flows. After that we
can focus on l2/l3. If we would be able to fit in in flows (some drivers
may), then ok. If not, we extend the api with couple of more l2/l3
related ndos. I see no problem there.
Well, it
On 08/24/14 22:24, Scott Feldman wrote:
On Aug 24, 2014, at 8:15 AM, Jamal Hadi Salim j...@mojatatu.com wrote:
With respect to focus on L2/L3, I have a pretty *good* hunch someone could
write a kernel module that gleans from the L2/L3 netlink echoes
already flying
around and translates
On 08/24/14 22:42, John Fastabend wrote:
In the L2 case we already have the fdb_add and fdb_del semantics that
are being used today by NICs with embedded switches. And we have a DSA
patch we could dig out of patchwork for those drivers.
Indeed. That is an excellent starting point of something
On 08/25/14 10:17, Thomas Graf wrote:
On 08/25/14 at 09:53am, Jamal Hadi Salim wrote:
fdb_add() *is* flow based. At least in my understanding, the whole
point here is to extend the idea of fdb_add() and make it understand
L2-L4 in a more generic way for the most common protocols.
The reason
On 08/25/14 10:54, Thomas Graf wrote:
On 08/24/14 at 11:15am, Jamal Hadi Salim wrote:
Let's keep vendors out of this discussion.
The API is from a vendor. It is clearly labelled as an OF API.
It covers well abstracting that vendors SDK to enable OF. That
is relevant info.
If it covers all
On 08/24/14 07:12, Thomas Graf wrote:
On 08/23/14 at 09:53pm, Jamal Hadi Salim wrote:
I get what you are saying but I don't see that to be the case here. I
don't see how this series proposes the OVS case as *the* interface.
The focus of the patches is on offloading flows (uses the
ovs
On 08/21/14 13:05, Florian Fainelli wrote:
2014-08-21 9:18 GMT-07:00 Jiri Pirko j...@resnulli.us:
The goal of this is to provide a possibility to suport various switch
chips. Drivers should implement relevant ndos to do so. Now there is a
couple of ndos defines:
- for getting physical switch id
On 03/27/14 03:21, Jiri Pirko wrote:
Wed, Mar 26, 2014 at 10:44:31PM CET, j...@mojatatu.com wrote:
Well, I think there are 2 main models to be considered:
1. OSV-like model, where everything is flows and that is the OneWay(tm)
mode you mentioned :)
2. clasic switch setting-like model
On 03/27/14 07:02, Thomas Graf wrote:
On 03/27/14 at 06:27am, Jamal Hadi Salim wrote:
There is definitely need beyond an ndo that is capable of
adding flows. You mention routes. Another example would be
devices capable of offloading iptables nft rules.
nod.
But wouldn't you want
On 03/27/14 08:00, Thomas Graf wrote:
It seems like we reached pretty good consensus on the model. What
remaining issues do you see with the port model proposed in v2?
Are we really following the same thread?
I dont see any rallying behind Jiri's approach from the
other folks who have their
Jiri,
The flow extensions may be distracting - note there are many
tables (L3, L2, etc) in such chips not just ACLs. And there's likely no
OneWay(tm) to add a flow. My view is probably to solve or reach an
agreement on the ports. Then resolve the different tables control/data
exposure.
On the
On 12-12-11 10:14 PM, Tom Herbert wrote:
This patch adds ipv6 set action functionality. It allows to change
traffic class, flow label, hop-limit, ipv6 source and destination
address fields.
I have to wonder about these patches and the underlying design
direction. Aren't these sort of things
On Sun, 2012-04-22 at 08:22 -0700, Stephen Hemminger wrote:
STT isn't really doing TCP, it just lying and pretending to be
TCP to allow TSO to work! There is no packet ordering, sequence
numbers or any real transport layer.
True. It is a nice engineering hack but even as a protocol
Jesse,
I empathize with effort youve put in, i really do; youve
already created the messaging from user space to kernel
and dammit it works; however, i dont agree with your reasoning.
The classifier action code is _exactly_ the same infrastructure.
The user space API/messaging already exists.
On Mon, 2011-11-28 at 21:04 +0800, Herbert Xu wrote:
You're right, a new classifier for the hash table would be the
best option.
I cant find one - you may. After staring at the code, I am also now
questioning if the existing bridge code couldnt have been re-used with
some small tweaks.
On Mon, 2011-11-28 at 13:54 +, Fischer, Anna wrote:
Yes, I mentioned this months ago, and I am surprised this critical
issue has never been picked up on and addressed. With a flaw like
this there is no chance this component can be used in any serious
virtualization deployment where
On Mon, 2011-11-28 at 07:27 -0800, Martin Casado wrote:
This is a common misunderstanding about OpenFlow. It does not require
the first packet of each flow to go to the controller.
I am reading this to mean that the switch CPU will resolve things?
Typically those tend to be tiny cpus.
In
On Mon, 2011-11-28 at 08:01 -0800, Ben Pfaff wrote:
Regarding OpenFlow rate limiting, in addition to Martin's response, Open
vSwitch has implemented controller rate limiting since day one. It is
documented in ovs-vswitchd.conf.db(5):
Ok, I think thats a good start. My experience says just
On Mon, 2011-11-28 at 10:34 -0800, Justin Pettit wrote:
On Nov 25, 2011, at 5:11 PM, Jamal Hadi Salim wrote:
Are you talking about ASICs on NICs?
I am indifferent - looking at it entirely from a control
perspective. i.e if i do ip link blah down on a port
i want that to work with zero
On Mon, 2011-11-28 at 10:44 -0800, Justin Pettit wrote:
I realize you chair an IETF standard with overlapping goals with
OpenFlow (ForCES), so you may have strong opinions about its design.
Yes, I do have strong opinions not really related to ForCES more towards
Linux. If i was to put ForCES
On Fri, 2011-11-25 at 11:52 -0800, Justin Pettit wrote:
On Nov 24, 2011, at 9:20 PM, Stephen Hemminger wrote:
A big difficulty is finding an appropriate hardware abstraction. I've worked
on porting
Open vSwitch to a few different vendors' switching ASICs, and they've all
looked quite
On Fri, 2011-11-25 at 12:20 -0800, Jesse Gross wrote:
The flow classifier isn't really designed to do rule lookup in the way
that OpenFlow/Open vSwitch does, since it's more about choosing which
fields are considered significant to the flow. I'm sure that it could
be extended in some way but
On Wed, 2011-11-23 at 15:15 +0100, Eric Dumazet wrote:
Or, we could stick documentation in kernel (Documentation/network/...),
so that we give credit to contributors to this essential part of the
network stack.
That would work - but i dont know how many users read
Documentation/network/
On Wed, 2011-11-23 at 08:05 -0800, John Fastabend wrote:
Makes sense in most cases. If you have a lot of flow setup/teardown
it may harm.
We could have a CONFIG option to always do locking in some
cases if thats not too ugly.
What i mean is RCU is useful when you have a substantially
On Wed, 2011-11-23 at 13:55 +0100, Eric Dumazet wrote:
Currently thinking about it. I was also waiting Tom Herbert BQL patches.
Excellent. I can test when you have something.
Several people are interested, and John Fastabend told me he plans to :
(1) rcu'ify classifiers/actions as needed
On Tue, 2011-11-22 at 15:11 -0800, Jesse Gross wrote:
As you mention, one of the biggest benefits of Open vSwitch is how
simple the kernel portions are (it's less than 6000 lines).
I said that was the reason _you_ were using to justify things
and i argue that is not accurate.
You will be
On Tue, 2011-11-22 at 18:30 -0800, John Fastabend wrote:
He is pushing and popping entire tags off 802.1Q for now but
you can easily imagine MPLS tags and all sorts of other things
people will _need_.
Lots of packet munging already happening with actions.
We can
59 matches
Mail list logo
