All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [next-queue PATCH v2 8/8] igb: Add support for adding offloaded clsflower filters
Date: Tue, 06 Mar 2018 13:26:05 -0800	[thread overview]
Message-ID: <87d10g28wi.fsf@intel.com> (raw)
In-Reply-To: <20180306112806.6fa39148@cakuba.netronome.com>

Hi,

Jakub Kicinski <kubakici@wp.pl> writes:

> On Tue, 06 Mar 2018 11:08:26 -0800, Vinicius Costa Gomes wrote:
>> >> +static int igb_parse_cls_flower(struct igb_adapter *adapter,
>> >> +				struct tc_cls_flower_offload *f,
>> >> +				int traffic_class,
>> >> +				struct igb_nfc_filter *input)
>> >> +{
>> >> +	if (f->dissector->used_keys &
>> >> +	    ~(BIT(FLOW_DISSECTOR_KEY_BASIC) |
>> >> +	      BIT(FLOW_DISSECTOR_KEY_CONTROL) |
>> >> +	      BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS) |
>> >> +	      BIT(FLOW_DISSECTOR_KEY_VLAN))) {
>> >> +		dev_err(&adapter->pdev->dev, "Unsupported key used: 0x%x\n",
>> >> +			f->dissector->used_keys);  
>> >
>> > This will probably trigger for opportunistic offload (non-skip_sw) and
>> > confuse users.
>> 
>> I see your point. I will change to 'dev_warn()', it should not surprise
>> users too much, right?
>
> Yes, I think that would be fine, other drivers are doing that already.
>
> IMHO best approach is to not print anything unless skip-sw is set.  If
> you used netlink's extack capability exclusively it would "just work".
> Extack will only carry the error in case offload is requested.  Could
> you consider using extack or do you have a preference to print into the
> logs?  You could do both, too.

I will go with extack-only, but I had to tweak the message a little as
there's no support for format strings in extack.

>
> You can get to extack via f->common->extack.


Cheers,
--
Vinicius

WARNING: multiple messages have this Message-ID (diff)
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Jakub Kicinski <kubakici@wp.pl>
Cc: intel-wired-lan@lists.osuosl.org, jeffrey.t.kirsher@intel.com,
	netdev@vger.kernel.org, jesus.sanchez-palencia@intel.com
Subject: Re: [next-queue PATCH v2 8/8] igb: Add support for adding offloaded clsflower filters
Date: Tue, 06 Mar 2018 13:26:05 -0800	[thread overview]
Message-ID: <87d10g28wi.fsf@intel.com> (raw)
In-Reply-To: <20180306112806.6fa39148@cakuba.netronome.com>

Hi,

Jakub Kicinski <kubakici@wp.pl> writes:

> On Tue, 06 Mar 2018 11:08:26 -0800, Vinicius Costa Gomes wrote:
>> >> +static int igb_parse_cls_flower(struct igb_adapter *adapter,
>> >> +				struct tc_cls_flower_offload *f,
>> >> +				int traffic_class,
>> >> +				struct igb_nfc_filter *input)
>> >> +{
>> >> +	if (f->dissector->used_keys &
>> >> +	    ~(BIT(FLOW_DISSECTOR_KEY_BASIC) |
>> >> +	      BIT(FLOW_DISSECTOR_KEY_CONTROL) |
>> >> +	      BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS) |
>> >> +	      BIT(FLOW_DISSECTOR_KEY_VLAN))) {
>> >> +		dev_err(&adapter->pdev->dev, "Unsupported key used: 0x%x\n",
>> >> +			f->dissector->used_keys);  
>> >
>> > This will probably trigger for opportunistic offload (non-skip_sw) and
>> > confuse users.
>> 
>> I see your point. I will change to 'dev_warn()', it should not surprise
>> users too much, right?
>
> Yes, I think that would be fine, other drivers are doing that already.
>
> IMHO best approach is to not print anything unless skip-sw is set.  If
> you used netlink's extack capability exclusively it would "just work".
> Extack will only carry the error in case offload is requested.  Could
> you consider using extack or do you have a preference to print into the
> logs?  You could do both, too.

I will go with extack-only, but I had to tweak the message a little as
there's no support for format strings in extack.

>
> You can get to extack via f->common->extack.


Cheers,
--
Vinicius

  reply	other threads:[~2018-03-06 21:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-02 18:43 [Intel-wired-lan] [next-queue PATCH v2 0/8] igb: offloading of receive filters Vinicius Costa Gomes
2018-03-02 18:43 ` Vinicius Costa Gomes
2018-03-02 18:43 ` [Intel-wired-lan] [next-queue PATCH v2 1/8] igb: Fix not adding filter elements to the list Vinicius Costa Gomes
2018-03-02 18:43   ` Vinicius Costa Gomes
2018-03-02 18:43 ` [Intel-wired-lan] [next-queue PATCH v2 2/8] igb: Fix queue selection on MAC filters on i210 and i211 Vinicius Costa Gomes
2018-03-02 18:43   ` Vinicius Costa Gomes
2018-03-02 18:43 ` [Intel-wired-lan] [next-queue PATCH v2 3/8] igb: Enable the hardware traffic class feature bit for igb models Vinicius Costa Gomes
2018-03-02 18:43   ` Vinicius Costa Gomes
2018-03-02 18:43 ` [Intel-wired-lan] [next-queue PATCH v2 4/8] igb: Add support for MAC address filters specifying source addresses Vinicius Costa Gomes
2018-03-02 18:43   ` Vinicius Costa Gomes
2018-03-02 18:43 ` [Intel-wired-lan] [next-queue PATCH v2 5/8] igb: Enable nfc filters to specify MAC addresses Vinicius Costa Gomes
2018-03-02 18:43   ` Vinicius Costa Gomes
2018-03-02 18:43 ` [Intel-wired-lan] [next-queue PATCH v2 6/8] igb: Add MAC address support for ethtool nftuple filters Vinicius Costa Gomes
2018-03-02 18:43   ` Vinicius Costa Gomes
2018-03-02 18:43 ` [Intel-wired-lan] [next-queue PATCH v2 7/8] igb: Add the skeletons for tc-flower offloading Vinicius Costa Gomes
2018-03-02 18:43   ` Vinicius Costa Gomes
2018-03-02 18:43 ` [Intel-wired-lan] [next-queue PATCH v2 8/8] igb: Add support for adding offloaded clsflower filters Vinicius Costa Gomes
2018-03-02 18:43   ` Vinicius Costa Gomes
2018-03-05 21:13   ` [Intel-wired-lan] " Jakub Kicinski
2018-03-05 21:13     ` Jakub Kicinski
2018-03-06 19:08     ` [Intel-wired-lan] " Vinicius Costa Gomes
2018-03-06 19:08       ` Vinicius Costa Gomes
2018-03-06 19:28       ` [Intel-wired-lan] " Jakub Kicinski
2018-03-06 19:28         ` Jakub Kicinski
2018-03-06 21:26         ` Vinicius Costa Gomes [this message]
2018-03-06 21:26           ` Vinicius Costa Gomes

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=87d10g28wi.fsf@intel.com \
    --to=vinicius.gomes@intel.com \
    --cc=intel-wired-lan@osuosl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.