Re: [ovs-dev] [RFC] Proposal for enhanced select groups
On Thu, Aug 28, 2014 at 10:11:57AM +0900, Simon Horman wrote:
> On Wed, Aug 27, 2014 at 09:51:59AM -0700, Ben Pfaff wrote:
> > On Wed, Aug 27, 2014 at 10:26:14AM +0900, Simon Horman wrote:
[snip]
> > The proposal seems reasonable on its own but given that EXT-350 allows a
> > standardized way to add group configuration extension I am not sure it
> > makes sense to add a specialized way to do that.
>
> Thanks, as discussed off-line, on closer examination I see that our
> proposal could fit into EXT-350 as a group property.
We have updated our proposal to use an EXT-350 group property.
The revised version is below.
We have also started on an implementation of EXT-350. Our current plan is
to implement EXT-350 as an OpenFlow 1.5 group_mod message. Let me know if
you would like us to make it some kind of experimenter message instead.
Proposal: Proposal for Group Selection Method Property
Version: 0.0.1
Contents
1. Introduction
2. How it Works
3. Experimenter Id
4. Experimenter Messages
5. History
1. Introduction
===
This text describes a Netronome Extension to OpenFlow 1.4 that allows a
controller to provide more information on the selection method for select
groups. This proposal is in the form of an enhanced select group type.
This may subsequently be proposed as an extension or update to
the OpenFlow specification.
2. How it works
===
A new Netronome group experimenter property is defined which provides
compatibility with the group mod message defined in EXT-350 to Open Flow
1.4.0 and allows parameters for the selection method of select groups to be
passed by the controller. In particular it allows controllers to:
* Specify the fields used for bucket selection by the select group.
* Designate the selection method used.
* Provide a non-field parameter to the selection method.
3. Experimenter ID
==
The Experimenter ID of this extension is:
NMX_VENDOR_ID = 0x1540
4. Group Experimenter Property
==
The following group property experimenter type defined by this extension.
enum nmx_group_mod_subtype {
NMXT_SELECTION_METHOD = 1
}
Modifications to the group table from the controller may be done with a
OFPT_GROUP_MOD message described in a draft of EXT-350, an extension to
the description found in Open Flow 1.4.0 section 7.3.4.3 Modify
Group Entry Message. Of relevance here is that EXT-350 allows properties
to be included in group mod messages.
This proposal is defined in terms of an implementation of struct
ofp_group_prop_experimenter which is described in EXT-350.
The implementation is:
struct nmx_group_prop_selection_method {
ovs_be16 type; /* OFPGPT_EXPERIMENTER. */
ovs_be16 length;/* Length in bytes of this property. */
ovs_be32 experimenter; /* NMX_VENDOR_ID. */
ovs_be32 exp_type; /* NMXT_SELECTION_METHOD. */
char selection_method[NXM_MAX_SELECTION_METHOD_LEN];
/* Null-terminated */
ovs_be64 selection_method_param; /* Non-Field parameter for
* bucket selection. */
struct ofp_match fields;/* Fields used for bucket selection.
* Variable size. */
}
OVS_ASSERT(sizeof(struct nmx_group_mod) == 24);
This property may only be used with group mod messages whose:
* command is OFPGC_ADD or OFPGC_MODIFY; and
* type is OFPGT_SELECT
The type field is the OFPGPT_EXPERIMENTER which is
defined in EXT-350 as 0x.
The experimenter field is the Experimenter ID (see 3).
The exp_type field is NMXT_SELECTION_METHOD.
The group selection_method is a null-terminated string which if non-zero
length specifies a selection method known to an underlying layer of the
switch. The value of NXM_MAX_SELECTION_METHOD_LEN is 16.
The group selection_method may be zero-length to request compatibility with
Open Flow 1.4.
The selection_method_param provides a non-field parameter for
the group selection_method. It must be all-zeros unless the
group selection_method is non-zero length.
The selection_method_param may for example be used as an initial value for
the hash of a hash group selection method.
The fields field is an ofp_match structure which includes the fields which
should be used as inputs to bucket selection. ofp_match is described in
Open Flow 1.4 section 7.2.2 Flow Match Structures.
Fields must not be specified unless the group selection_method is non-zero
length.
The pre-requisites for fields specified must be satisfied in the match for
any flow that uses the group.
Masking is allowed but not required for fields whose TLVs allow masking.
The fields may for example be used as the fields that are hashed
by a hash group selection method.
5. History
==
This proposal has been developed independently of any similar work in this
area. No such work is known.
Re: [ovs-dev] [RFC] Proposal for enhanced select groups
On Thu, Aug 28, 2014 at 10:12:49AM +0900, Simon Horman wrote: > On Wed, Aug 27, 2014 at 03:03:53PM -0500, Jesse Gross wrote: > > On Wed, Aug 27, 2014 at 11:51 AM, Ben Pfaff wrote: > > > On Wed, Aug 27, 2014 at 10:26:14AM +0900, Simon Horman wrote: > > >> On Fri, Aug 22, 2014 at 08:30:08AM -0700, Ben Pfaff wrote: > > >> > On Fri, Aug 22, 2014 at 09:19:41PM +0900, Simon Horman wrote: > > >> What we would like to do is to provide something generally useful > > >> which may be used as appropriate to: > > > > > > I'm going to skip past these ideas, which do sound interesting, because > > > I think that they're more for Pravin and Jesse than for me. I hope that > > > they will provide some reactions to them. > > > > For the hardware offloading piece in particular, I would take a look > > at the discussion that has been going on in the netdev mailing list. I > > think the general consensus (to the extent that there is one) is that > > the hardware offload interface should be a block outside of OVS and > > then OVS (mostly likely from userspace) configures it. > > Thanks, I am now digesting that conversation. A lively conversation indeed. We are left with two questions for you: 1. Would you look at a proposal (I have some rough code that even works) for a select group action in the datapath prior to the finalisation of the question of offloads infrastructure in the kernel? From our point of view we would ultimately like to use such an action to offload to hardware. But it seems that there might be use-cases (not the one that I have rough code for) where such an action may be useful. For example to allow parts of IPVS to be used to provide stateful load balancing. Put another: It doesn't seem that a select group action is dependent on an offloads tough there are cases where they could be used together. 2. Would you consider an set of offload-hooks for Open vSwitch at this time? These could be backed by loading a module that implements the relevant hooks. And in the longer term one such module (possibly to rule them all) could be implemented using the kernel offload API that has been the subject of recent lively discussion. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
On Fri, Aug 29, 2014 at 10:20:55AM -0400, Jamal Hadi Salim wrote: > 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 OF check-box > >>to sell more chips, but at the end there is not a single HW > >>that is fully OF compliant. OF brand is still around, but > >>OF 2.0 is not tcam+action anymore. > >>Imo trying to standardize HW offload interface based on OF 1.x > >>principles is strange. > > > 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, > is where i start taking issue. I have a few things that i offload > to hardware with speacilized classifiers such that i object strongly > to the approach this driver has taken. My reading of this thread is that allowing different classifiers is not under dispute. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] BFD integration into FastFailover Group Table
1) Ok, I will read up on OFPPS_LIVE, clean up my code and send in an appropriate Patch for BFD support 2) This was mainly a point of discussion that I am curious towards. I am concerned that checking all BFD, OAM, CFM, etc., sequentially may harm the throughput of the function odp_port_is_alive(). Whereas a single flag status up/down (OFPPS_LIVE) may cause synchronization problems if one configures multiple failure mechanisms in parallel. Instead, we might introduce a single byte that equals 0x00 if none of the mechanisms detect downtime. Then we reserve a single bit per mechanism (f.e. 0x01 for administrative port status, 0x02 for OAM/CFM, 0x04 for BFD). Meaning that a non 0x00 value means the port is not live resulting in a single if-statement instead of multiple nested if-statements with double checks on whether given mechanisms are actually configured, etc., and different mechanisms may report up- and downtime without interference by setting there respective bit to 1. Though I realize this requires quite some work. Best, Niels From: Ben Pfaff [b...@nicira.com] Sent: Friday, August 29, 2014 11:02 PM To: Niels van Adrichem Cc: dev@openvswitch.org Subject: Re: [ovs-dev] BFD integration into FastFailover Group Table On Fri, Aug 29, 2014 at 01:15:53PM +, Niels van Adrichem wrote: > For some experiments I did around April/May for a paper I wrote I > changed some sourcecode to ofproto-dpif-xlate.c to have the FastFailover > Group Table look at the BFD status directly. > We did this because we found that although the BFD status flags changed > in time, interface status remained up (which might or might not already > have been solved by now) and hence the FastFailover rule would not > select the backup forwarding rule. Furthermore, our experiments showed > that bringing the interface status down manually could take slightly > over 50 ms before the FastFailover would kick in [1]. As we wanted "even > faster" recovery, we decided to have the function odp_port_is_alive() > also look at the BFD status itself [2]. Doing this also decreased the > number of packets when an interface became live again, as the Fast > Failover rule would not revert sending to the primary rule before BFD > confirmed a live link. > > If you are interested I can rewrite the patch to confirm to the > appropriate coding lay-out and make sure it applies to the current state > of the file. It sounds like a good idea. I am not sure why that function doesn't already check BFD and CFM state. It seems that it should. It also seems that OVS seems to be missing an implementation of OFPPS_LIVE in OpenFlow port state. We should fix that too. > Perhaps instead of checking the BFD status, I could include a > *synchronized* per-interface flag that f.e. equals 0x00 when all > configured link state detection mechanisms detect live links, 0x01 when > BFD detects an error, 0x02 when Ethernet OAM detects an error, 0x03 when > both do, etc. In that case you can check status from multiple detection > mechanisms without the need to iterate through all of them, hence > improving the throughput of OVS. How do you think about that? Code cleanups are always welcome, although I don't entirely understand this proposal. Thanks, Ben. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Regarding implementation of Importance field in flow.
Hi Team, I am working on addition of the "IMPORTANCE" field in the add-flow command as per the Openflow-specs 1.4. As I am new to openvswitch and have just started exploring its code, can anyone tell me from where to start, this addition of IMPORTANCE field in the flow. I mean the files where changes are to be done or from where to start for implementation of this. Regards Shashwat Srivastava Mailto: shashwat.srivast...@tcs.com Website: http://www.tcs.com Experience certainty. IT Services Business Solutions Consulting =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Open Vswitch Feature Enhancement- Provider Bridging Feature
Hi Ben and Team, I have checked the features list supported in open Vswitch.I found that following feature is not yet supported: - 802.1ad (provider bridging) We are thinking to contribute in above feature. Can you please provide your inputs/opinions and suggestion for it? Also can you please provide any documents link which can help us to understand the code flow in faster way? Thanks and Regards, Hiteshi Madan =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] how to match and set pkt_mark field in ofctl?
On 09/01/14 at 11:38am, loy wolfe wrote: > Hi, > > I see in the doc[1] that there is pkt_mark field, but I didn't find any > description in the ofctl manual. So, can I match against this field, and > set it in the action? pkt_mark seems covered in ovs-ofctl(8): pkt_mark=value[/mask] Matches packet metadata mark value either exactly or with optional mask. The mark is associated data that may be passed into other system components in order to facilitate interaction between subsystems. On Linux this corresponds to the skb mark but the exact implementation is platform-dependent. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Gentile utente
Gentile utente La tua email è superato 2 GB creati dal webmaster, State attualmente in esecuzione a 2.30GB, che non può inviare o ricevere nuovi messaggi Entro il prossimo 24 ore prima di averne verificato email account. Inserisci i tuoi dati qui sotto per verificare il tuo account: (1) E-mail: (2) Nome: (3) Password: (4) Conferma Password: grazie Amministratore di sistema. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [RFC] Proposal for enhanced select groups
On 09/01/14 at 05:10pm, Simon Horman wrote: > We are left with two questions for you: > > 1. Would you look at a proposal (I have some rough code that even works) >for a select group action in the datapath prior to the finalisation >of the question of offloads infrastructure in the kernel? > >From our point of view we would ultimately like to use such an action to >offload to hardware. But it seems that there might be use-cases (not the >one that I have rough code for) where such an action may be useful. For >example to allow parts of IPVS to be used to provide stateful load >balancing. > >Put another: It doesn't seem that a select group action is dependent on >an offloads tough there are cases where they could be used together. Are you maintaining additional tables for the select classifier? Personally I would be very interested in seeing the code as multiple nexthops with load balancing behaviour is one of the few things that the current OVS datapath cannot handle. I would favour if the implementation of it is something that is reusable for the offload API. > 2. Would you consider an set of offload-hooks for Open vSwitch at this time? > >These could be backed by loading a module that implements the relevant >hooks. And in the longer term one such module (possibly to rule them >all) could be implemented using the kernel offload API that has >been the subject of recent lively discussion. What aspects are not yet covered in the offload API as proposed? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [RFC] Proposal for enhanced select groups
2014/09/01 21:40 "Thomas Graf" : > > On 09/01/14 at 05:10pm, Simon Horman wrote: > > We are left with two questions for you: > > > > 1. Would you look at a proposal (I have some rough code that even works) > >for a select group action in the datapath prior to the finalisation > >of the question of offloads infrastructure in the kernel? > > > >From our point of view we would ultimately like to use such an action to > >offload to hardware. But it seems that there might be use-cases (not the > >one that I have rough code for) where such an action may be useful. For > >example to allow parts of IPVS to be used to provide stateful load > >balancing. > > > >Put another: It doesn't seem that a select group action is dependent on > >an offloads tough there are cases where they could be used together. > > Are you maintaining additional tables for the select classifier? > Personally I would be very interested in seeing the code as multiple > nexthops with load balancing behaviour is one of the few things that > the current OVS datapath cannot handle. I would favour if the > implementation of it is something that is reusable for the offload > API. My current prototype implements a select action which may contain one or more buckets which in turn may contain actions. It us very much based on the select group of OpenFlow 1.4. I will see about making it available. > > 2. Would you consider an set of offload-hooks for Open vSwitch at this time? > > > >These could be backed by loading a module that implements the relevant > >hooks. And in the longer term one such module (possibly to rule them > >all) could be implemented using the kernel offload API that has > >been the subject of recent lively discussion. > > What aspects are not yet covered in the offload API as proposed? I will look over the proposed API more closely but nothing stands out at this time. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] travis: Announce travis CI and new build list in NEWS and CONTRIBUTING
Signed-off-by: Thomas Graf --- CONTRIBUTING | 6 ++ NEWS | 3 +++ 2 files changed, 9 insertions(+) diff --git a/CONTRIBUTING b/CONTRIBUTING index f4d2c97..dfbb171 100644 --- a/CONTRIBUTING +++ b/CONTRIBUTING @@ -41,6 +41,12 @@ Testing is also important: - A patch that modifies xenserver code should be tested on XenServer before submission. +If you are using GitHub, then you may utilize the travis-ci.org CI build +system by linking your GitHub repository to it. This will run some of +the above tests automatically when you push changes to your repository. +See the "Continuous Integration with Travis-CI" in the INSTALL file for +details on how to set it up. + Email Subject - diff --git a/NEWS b/NEWS index 5059358..b245359 100644 --- a/NEWS +++ b/NEWS @@ -22,6 +22,9 @@ Post-v2.3.0 - test-controller has been renamed ovs-testcontroller at request of users who find it useful for testing basic OpenFlow setups. It is still not a necessary or desirable part of most Open vSwitch deployments. + - Support for travis-ci.org based continuous integration builds has been + added. Build failures are reported to bu...@openvswitch.org. See INSTALL + file for additional details. v2.3.0 - 14 Aug 2014 -- 1.9.3 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] ovs-vsctl: Fix leaked error string in cmd_remove()
Signed-off-by: Thomas Graf
---
utilities/ovs-vsctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utilities/ovs-vsctl.c b/utilities/ovs-vsctl.c
index 37d8b3c..2cd389b 100644
--- a/utilities/ovs-vsctl.c
+++ b/utilities/ovs-vsctl.c
@@ -3529,11 +3529,11 @@ cmd_remove(struct vsctl_context *ctx)
error = ovsdb_datum_from_string(&rm, &rm_type,
ctx->argv[i], ctx->symtab);
if (error && ovsdb_type_is_map(&rm_type)) {
-free(error);
rm_type.value.type = OVSDB_TYPE_VOID;
die_if_error(ovsdb_datum_from_string(&rm, &rm_type,
ctx->argv[i], ctx->symtab));
}
+free(error);
ovsdb_datum_subtract(&old, type, &rm, &rm_type);
ovsdb_datum_destroy(&rm, &rm_type);
}
--
1.9.3
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] test-stp: Fix leak of open file descriptor for input_file
Signed-off-by: Thomas Graf
---
tests/test-stp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/test-stp.c b/tests/test-stp.c
index 9ca9c6c..c4e5933 100644
--- a/tests/test-stp.c
+++ b/tests/test-stp.c
@@ -666,6 +666,7 @@ test_stp_main(int argc, char *argv[])
free(bridge);
}
free(tc);
+fclose(input_file);
}
OVSTEST_REGISTER("test-stp", test_stp_main);
--
1.9.3
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] test-bitmap: Fix multiple minor memory leaks
Signed-off-by: Thomas Graf --- tests/test-bitmap.c | 5 + 1 file changed, 5 insertions(+) diff --git a/tests/test-bitmap.c b/tests/test-bitmap.c index b1274e3..3644419 100644 --- a/tests/test-bitmap.c +++ b/tests/test-bitmap.c @@ -56,6 +56,9 @@ test_bitmap_equal(void) assert(!bitmap_equal(a, b, 11 * BITMAP_ULONG_BITS - 1)); assert(!bitmap_equal(a, b, 11 * BITMAP_ULONG_BITS - (BITMAP_ULONG_BITS - 1))); + +free(b); +free(a); } /* Tests bitmap_scan. */ @@ -107,6 +110,8 @@ test_bitmap_scan(void) assert(bitmap_scan(a, false, 0, MAX_BITS - 1) == BITMAP_ULONG_BITS - 1); bitmap_set0(a, 0); assert(bitmap_scan(a, false, 0, MAX_BITS - 1) == 0); + +free(a); } static void -- 1.9.3 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
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, is where i start taking issue. I have a few things that i offload to hardware with speacilized classifiers such that i object strongly to the approach this driver has taken. My reading of this thread is that allowing different classifiers is not under dispute. I am not sure how you reached that conclusion by reading this thread;-> But i would be glad if that was the conclusion and i missed it. cheers, jamal ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [dpdk patch 2/8] netdev-dpdk: Add function for getting the socket_id of netdev-dpdk.
> > > This should be part of netdev_class api rather than dpdk specific API. > we should try to minimize dpdk specific call in dpif-netdev layer. > > One more issue I noticed in this series is that socket and numa is > used interchangeably, can we use just one? > > I'll add it to netdev_class api. and I'll always use 'numa'. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [dpdk patch 4/8] netdev-dpdk: Create 'number of dpdk ifaces on same cpu socket' rx queues and 'number of cpu cores' tx queues for each dpdk interface.
On Sat, Aug 30, 2014 at 12:02 PM, Pravin Shelar wrote:
> On Mon, Aug 11, 2014 at 9:56 PM, Alex Wang wrote:
> > Before this commit, ovs only creates one tx/rx queue for each
> > dpdk interface and uses only one poll thread for handling the
> > I/O of all dpdk interfaces. As one step toward using multiple
> > poll threads, this commit makes ovs, by default, create same
> > number of rx queues as the number dpdk interfaces on the cpu
> > socket. Also each dpdk interface will have one tx queue for
> > each cpu core, even though not all of those queues will be
> > used.
> >
>
> Generally we should describe subject in less than 70 characters.
> Commit msg should explain why we are introducing this change. It is
> not clear from the patch the relation between number of core on socket
> and rx queues.
>
>
Thx, I'll use the 70 characters rule, thought it was 80,
Also, I'll shed light on how upcoming patches relates to this patch.
>
> > @@ -179,7 +180,9 @@ struct netdev_dpdk {
> > int port_id;
> > int max_packet_len;
> >
> > -struct dpdk_tx_queue tx_q[NR_QUEUE];
> > +struct dpdk_tx_queue *tx_q;
> > +int n_tx_q;
> > +int n_rx_q;
> >
> There is already member in struct netdev called n_rxq to represent
> number of rx_queues, we should use that directly.
> tx_queues are not visible to dpif-netdev, but later patches will make
> them visible, so we should add another member n_txq to struct netdev.
> netdev-provide should be a passive layer, driven by dpif-netdev. Logic
> of calculating number of queues should is in dpif-netdev, We can add
> another API to open multi queue devices like dpdk.
>
i'm good with adding n_txq to the 'struct netdev'.
so i think what you suggest are the following:
- add n_txq to 'struct netdev', and add new struct 'struct netdev_txq'
- add functions netdev_set_multiq() in 'netdev-provider.h' for configuring
the n_txq, n_rxq
- like rxq_recv() functions, the send() function will take in 'struct
netdev_txq'
as argument
right?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [dpdk patch 5/8] dpif-netdev: Create 'number of dpdk ifaces on cpu socket' pmd threads for each cpu socket.
>
> > static struct dp_netdev_port *dp_netdev_lookup_port(const struct
> dp_netdev *dp,
> > @@ -281,6 +281,15 @@ struct dp_netdev_actions
> *dp_netdev_flow_get_actions(
> > const struct dp_netdev_flow *);
> > static void dp_netdev_actions_free(struct dp_netdev_actions *);
> >
> > +/* Represents the PMD configuration on a cpu socket. */
> > +struct pmd_socket {
> > +struct dp_netdev *dp;
> > +struct latch exit_latch;
> > +struct pmd_thread *pmd_threads;
> > +int socket_id;
> > +int n_pmd_threads;
> > +};
> > +
> We should keep socket to core mapping in numa module rather than in
> dpif-netdev.
>
In my future patches (for per pmd cls/flowtable), i removed the pmd_socket.
I'll just move the change forward...
> I am not sure why exit latch needs to be per socket, it is global
> today, it should be ok for now, no?
>
>
I'll make the 'exit latch' per pmd thread, because, for this optimization:
- when dpdk port is deleted, if it is the last dpdk port on the socket,
all pmd threads on the socket will be removed,
- using global exit latch will cause all pmd threads removed,
> > static void *
> > pmd_thread_main(void *f_)
> > {
> > struct pmd_thread *f = f_;
> > -struct dp_netdev *dp = f->dp;
> > +struct dp_netdev *dp = f->socket->dp;
> > unsigned int lc = 0;
> > struct rxq_poll *poll_list;
> > +struct non_local_pmd_dev *dev_list;
> > unsigned int port_seq;
> > -int poll_cnt;
> > +int poll_cnt, dev_cnt;
> > int i;
> >
> > poll_cnt = 0;
> > +dev_cnt = 0;
> > poll_list = NULL;
> > +dev_list = NULL;
> >
> > -pmd_thread_setaffinity_cpu(f->id);
> > +pmd_thread_setaffinity_cpu(f->core_id);
> > reload:
> > poll_cnt = pmd_load_queues(f, &poll_list, poll_cnt);
> > +dev_cnt = pmd_get_non_local_pmd_dev(f, &dev_list, dev_cnt);
> > atomic_read(&f->change_seq, &port_seq);
> >
> > for (;;) {
> > @@ -1682,6 +1777,10 @@ reload:
> > dp_netdev_process_rxq_port(dp, poll_list[i].port,
> poll_list[i].rx);
> > }
> >
> > +for (i = 0; i < dev_cnt; i++) {
> > +netdev_dpdk_flush_non_local(dev_list[i].dev, f->core_id);
> > +}
> > +
>
> In transmit function we can flush if this is remote queue. To optimize
> remote queue check on every xmit, we can add remote flag to
> dpdk-netdev queue.
>
may i know more about the reason you want to flush for every remote tx pkt?
- is it for packet order concern?
i'm not sure how expensive it is to call the tx function? but still think
we
should batch the remote tx here,
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [dpdk patch 6/8] netdev-dpdk: Add function for configuring rx queues for all dpdk interfaces.
>
>
> > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> > index 012ee68..3013df5 100644
> > --- a/lib/netdev-dpdk.c
> > +++ b/lib/netdev-dpdk.c
> > @@ -130,6 +130,8 @@ enum { DRAIN_TSC = 20ULL };
> >
> > static int rte_eal_init_ret = ENODEV;
> >
> > +static size_t dpdk_rx_queues OVS_GUARDED_BY(dpdk_mutex);
> > +
> There is no need to have this variable if netdev_open_multiq() accepts
> number of rx and tx queues.
>
Agree, based on comments from previous patches,
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] Broken build on MSVC
MSVC does not like variable length array either.
This patch treats the following error:
lib/dpif-netdev.c(2272) :
error C2057: expected constant expression
lib/dpif-netdev.c(2272) :
error C2466: cannot allocate an array of constant size 0
lib/dpif-netdev.c(2272) :
error C2133: 'batches' : unknown size
lib/dpif-netdev.c(2273) :
error C2057: expected constant expression
lib/dpif-netdev.c(2273) :
error C2466: cannot allocate an array of constant size 0
lib/dpif-netdev.c(2273) :
error C2133: 'mfs' : unknown size
lib/dpif-netdev.c(2274) :
error C2057: expected constant expression
lib/dpif-netdev.c(2274) :
error C2466: cannot allocate an array of constant size 0
lib/dpif-netdev.c(2274) :
error C2133: 'rules' : unknown size
lib/dpif-netdev.c(2363) :
warning C4034: sizeof returns 0
lib/dpif-netdev.c(2381) :
error C2057: expected constant expression
lib/dpif-netdev.c(2381) :
error C2466: cannot allocate an array of constant size 0
lib/dpif-netdev.c(2381) : error C2133: 'keys' : unknown size
make[2]: *** [lib/dpif-netdev.lo] Error 1
Signed-off-by: Alin Gabriel Serdean
---
lib/dpif-netdev.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 0ccf47d..38bd6a7 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -2263,10 +2263,10 @@ fast_path_processing(struct dp_netdev *dp, struct
emc_cache *flow_cache,
struct dpif_packet **packets, size_t cnt,
struct pkt_metadata *md, struct netdev_flow_key *keys)
{
-#ifndef __CHECKER__
+#if !defined(__CHECKER__) && !defined(_WIN32)
const size_t PKT_ARRAY_SIZE = cnt;
#else
-/* Sparse doesn't like variable length array */
+/* Sparse or MSVC doesn't like variable length array */
enum { PKT_ARRAY_SIZE = NETDEV_MAX_RX_BATCH };
#endif
struct packet_batch batches[PKT_ARRAY_SIZE];
@@ -2372,10 +2372,10 @@ static void
dp_netdev_input(struct dp_netdev *dp, struct emc_cache *flow_cache,
struct dpif_packet **packets, int cnt, struct pkt_metadata *md)
{
-#ifndef __CHECKER__
+#if !defined(__CHECKER__) && !defined(_WIN32)
const size_t PKT_ARRAY_SIZE = cnt;
#else
-/* Sparse doesn't like variable length array */
+/* Sparse or MSVC doesn't like variable length array */
enum { PKT_ARRAY_SIZE = NETDEV_MAX_RX_BATCH };
#endif
struct netdev_flow_key keys[PKT_ARRAY_SIZE];
--
1.9.0.msysgit.0
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
Mon, Sep 01, 2014 at 06:37:05PM CEST, j...@mojatatu.com wrote: >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, >>>is where i start taking issue. I have a few things that i offload >>>to hardware with speacilized classifiers such that i object strongly >>>to the approach this driver has taken. >> >>My reading of this thread is that allowing different classifiers >>is not under dispute. > > >I am not sure how you reached that conclusion by reading this thread;-> >But i would be glad if that was the conclusion and i missed it. Jamal, please be ensured that no one I know of is against future different classifiers. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
On 09/01/14 16:28, Jiri Pirko wrote: Jamal, please be ensured that no one I know of is against future different classifiers. Ok, glad to hear that. The patches and/or some of the discussion were not projecting that view. Even for the flow case, I am pretty sure we are going to need a few iterations before we settle on a general consensus. cheers, jamal ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
