That looks ok to me. However, for the sake of clarity, I would rename
"void *dm" to "void *priv".
In fact, in the SDK framework (D2.3) the "dm" pointer refers to the Data
Model of a component implemented in the stack (and not in the plugins). In
this case, there is basically no DM, since PFT is all policy.
The "priv" pointer, instead, refers to the policy-set-specific
implementation (which is our case).
For more information please refer to D2.3.
2015-06-02 14:40 GMT+02:00 Sander Vrijders <sander.vrijders@xxxxxxxxxxxxxx>:
I discussed a new API for the PFT in kernel space with Miquel and
Vincenzo. You can find the changes here:
Basically, as I mentioned in my last e-mail, the PFT policy needs to be
in charge of its own data model. It has to react to modpdufwd_entry
messages to fill the DM. I will now implement the default policy set for
link state routing for the PFT.
On 06/01/2015 03:56 PM, Sander Vrijders wrote:
We are in the process of changing the PFT policy hook. Currently the
policy set only implements the following function:
int (* next_hop)(struct pft_ps * ps,
struct pci * pci,
port_id_t ** ports,
size_t * count);
/* Reference used to access the PFT data model. */
struct pft * dm;
and uses dm to access the PFT implementation that is still in pft.c,
which is a table that consists of entries that map destination to a list
of next hops. However, since the PFT implementation depends on the table
being used (for instance for LFA, this is a table with a normal port-id
and an alternate port-id), the policy set should be extended to keep the
table in its internal implementation. It should have extra functions for
instance to parse the PDUMODFWD message. I will be performing changes to
the pft policy set API and move code from pft.c to the default pft
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - iMinds
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
T: +32 9 33 14977 ; T Secr: +32 9 33 14900
F: +32 9 33 14899
W : www.ibcn.intec.UGent.be