From: Kieran Mansley <kmansley@solarflare.com>
To: <dev@dpdk.org>
Cc: <adrien.mazarguil@6wind.com>
Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification API
Date: Mon, 1 Aug 2016 16:08:51 +0100 [thread overview]
Message-ID: <579F6603.4030801@solarflare.com> (raw)
Apologies for coming a little late to this thread about the proposed new
API for filtering etc.
I've reviewed it based on Solarflare's needs and hardware capabilities,
and think the proposal is likely to be a big improvement on the current
system.
I worry slightly that the goal of having applications that are not aware
of the hardware they are running on will be difficult to meet. My guess
is that the different hardware platforms will have so little overlap in
the functionality they support that to get best performance the
applications will still be heavily tailored to the subsets of the API
that the hardware they are using provides. The discussion of filter
priorities is a good example of this: to get best performance the
application will want to use the hardware's filtering capabilities to do
all the heavy lifting, but the abilities of different NICs to support
particular priorities and combinations of filters will mean what works
very well for one NIC may well return "I can't do that" for another, and
vice versa.
One suggestion for extending the API further would be to allow it to
also describe transmit filters as well as receive filters.
There are also some filters that can prove very useful to our customers
that while they could be achieved through the careful insertion of
multiple filters with the right order and priorities, could be made more
application-friendly by having a more meaningful alias. For example:
- multicast-mismatch (all multicast traffic that doesn't match another
filter and would otherwise be discarded)
- unicast-mismatch (all unicast traffic that doesn't match another
filter and would otherwise be discarded)
- all-multicast (all multicast traffic)
- all-unicast (all unicast traffic)
Finally, I wonder if any thought has been given to dealing with
situations where there is a conflict between different virtual or
physical functions. E.g. attempting to insert a MAC filter on one VF
that would steal traffic destined to a different VF. Will it be up to
each driver to enforce these sorts of policies or will there be a
general vendor-neutral framework to deal with this?
I should reiterate that I think this will be a big improvement, so thank
you for proposing it.
Kieran
The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited.
next reply other threads:[~2016-08-01 15:28 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-01 15:08 Kieran Mansley [this message]
2016-08-03 15:19 ` Adrien Mazarguil
-- strict thread matches above, loose matches on Subject: below --
2016-07-05 18:16 Adrien Mazarguil
2016-07-07 7:14 ` Lu, Wenzhuo
2016-07-07 10:26 ` Adrien Mazarguil
2016-07-19 8:11 ` Lu, Wenzhuo
2016-07-19 13:12 ` Adrien Mazarguil
2016-07-20 2:16 ` Lu, Wenzhuo
2016-07-20 10:41 ` Adrien Mazarguil
2016-07-21 3:18 ` Lu, Wenzhuo
2016-07-21 12:47 ` Adrien Mazarguil
2016-07-22 1:38 ` Lu, Wenzhuo
2016-07-07 23:15 ` Chandran, Sugesh
2016-07-08 13:03 ` Adrien Mazarguil
2016-07-11 10:42 ` Chandran, Sugesh
2016-07-13 20:03 ` Adrien Mazarguil
2016-07-15 9:23 ` Chandran, Sugesh
2016-07-15 10:02 ` Chilikin, Andrey
2016-07-18 13:26 ` Chandran, Sugesh
2016-07-15 15:04 ` Adrien Mazarguil
2016-07-18 13:26 ` Chandran, Sugesh
2016-07-18 15:00 ` Adrien Mazarguil
2016-07-20 16:32 ` Chandran, Sugesh
2016-07-20 17:10 ` Adrien Mazarguil
2016-07-21 11:06 ` Chandran, Sugesh
2016-07-21 13:37 ` Adrien Mazarguil
2016-07-22 16:32 ` Chandran, Sugesh
2016-07-08 11:11 ` Liang, Cunming
2016-07-08 12:38 ` Bruce Richardson
2016-07-08 13:25 ` Adrien Mazarguil
2016-07-11 3:18 ` Liang, Cunming
2016-07-11 10:06 ` Adrien Mazarguil
2016-07-11 10:41 ` Jerin Jacob
2016-07-21 19:20 ` Adrien Mazarguil
2016-07-23 21:10 ` John Fastabend
2016-08-02 18:19 ` John Fastabend
2016-08-03 14:30 ` Adrien Mazarguil
2016-08-03 18:10 ` John Fastabend
2016-08-04 13:05 ` Adrien Mazarguil
2016-08-09 21:24 ` John Fastabend
2016-08-10 11:02 ` Adrien Mazarguil
2016-08-10 16:35 ` John Fastabend
2016-07-21 8:13 ` Rahul Lakkireddy
2016-07-21 17:07 ` Adrien Mazarguil
2016-07-25 11:32 ` Rahul Lakkireddy
2016-07-25 16:40 ` John Fastabend
2016-07-26 10:07 ` Rahul Lakkireddy
2016-08-03 16:44 ` Adrien Mazarguil
2016-08-03 19:11 ` John Fastabend
2016-08-04 13:24 ` Adrien Mazarguil
2016-08-09 21:47 ` John Fastabend
2016-08-10 13:37 ` Adrien Mazarguil
2016-08-10 16:46 ` John Fastabend
2016-08-19 21:13 ` John Daley (johndale)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=579F6603.4030801@solarflare.com \
--to=kmansley@solarflare.com \
--cc=adrien.mazarguil@6wind.com \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).