On 9/5/17, 1:30 AM, "Yuanhan Liu" <[email protected]> wrote:
On Fri, Sep 01, 2017 at 10:38:37PM +0000, Darrell Ball wrote:
>
>
> On 8/29/17, 7:33 PM, "Yuanhan Liu" <[email protected]> wrote:
>
> On Wed, Aug 30, 2017 at 02:02:23AM +0000, Darrell Ball wrote:
> >
> > > +#define MAX_RTE_FLOW_ITEMS 100
> > > +#define MAX_RTE_FLOW_ACTIONS 100
> > >
> > > I guess these are temporary
> >
> > Yes, the hardcoded number is really hacky.
> >
> > > Do we need to do a rte query during initialization ?
> >
> > query on what?
> >
> > [Darrell]
> > I mean somehow the max hardware resources available at
> > dev initialization time ? I realize this is non-trivial overall.
>
> I see you point then. I don't think it's needed then. I'm also not
> aware of there are such limitations existed (say, how many patterns
> are supported). I think we just add patterns as many as we can and
> let the driver to figure out the rest. If the flow creation is failed,
> we skip the hw offload, with an error message provided.
>
> [Darrell]
> I understand the present intention.
> But for future enhancements, maybe it would be good to display the max
capability/capacity and
> remaining capacity to the user in some way.
Agreed, and that's also what in my mind. It's some work in DPDK though.
> This brings back another discussion point: having user specification of
HWOL flows
> is starting to look more useful,
Are you introducing some new (CLI) interfaces? Could you give a bit more
detailes here?
[Darrell]
Maybe something wild like this with a special dp only action ‘in_queue’ or
‘hwol_in_queue’ ?
ovs-appctl dpctl/mod-flow
"in_port(1),eth(),eth_type(0x800),ipv4(src=1.1.1.1,dst=2.2.2.2)" in_queue(3)
It feels weird to do this as a full Openflow extension since it is special HW
centric, but maybe that is also
a yet more wild possibility. It would be better to fix the NICs/drivers than to
go here.
> as it helps the queue action issue and HWOL
> capacity planning/predictability for high value flows.
Yes, I would think so.
--yliu
>
> > > static (inline) function maybe ?
> >
> > Indeed. I'm not a big fan of macro like this. Let me turn it to
function
> > next time. I see no reason to make it inline (explicitly)
though: it's
> > not in data path. Moreover, it's likely it will be inlined
implicitly by
> > compiler.
> >
> > [Darrell]
> > I put ‘(inline)’ in parentheses because we would never specify it
explicitly,
> > since gcc would likely inline anyways.
>
> I see. Sorry for misunderstanding.
>
> --yliu
>
>
>
>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
