netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Florian Fainelli <f.fainelli@gmail.com>,
	intel-wired-lan@lists.osuosl.org
Cc: jeffrey.t.kirsher@intel.com, netdev@vger.kernel.org,
	jesus.sanchez-palencia@intel.com
Subject: Re: [next-queue PATCH 5/8] igb: Add support for ethtool MAC address filters
Date: Mon, 26 Feb 2018 11:30:51 -0800	[thread overview]
Message-ID: <874lm3blas.fsf@intel.com> (raw)
In-Reply-To: <A3A9616A-04ED-4E50-B82B-58BDED43F975@gmail.com>

Hi,

Florian Fainelli <f.fainelli@gmail.com> writes:

> On February 23, 2018 5:20:33 PM PST, Vinicius Costa Gomes <vinicius.gomes@intel.com> wrote:
>>This adds the capability of configuring the queue steering of arriving
>>packets based on their source and destination MAC addresses.
>>
>>In practical terms this adds support for the following use cases,
>>characterized by these examples:
>>
>>$ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
>>(this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
>>to the RX queue 0)
>>
>>$ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3
>>(this will direct packets with destination address "44:44:44:44:44:44"
>>to the RX queue 3)
>>
>>Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
>>---
>
> [snip]
>
>>diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c
>>b/drivers/net/ethernet/intel/igb/igb_ethtool.c
>>index 143f0bb34e4d..d8686a0f5b5d 100644
>>--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
>>+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
>>@@ -152,6 +152,9 @@ static const char
>>igb_priv_flags_strings[][ETH_GSTRING_LEN] = {
>> 
>> #define IGB_PRIV_FLAGS_STR_LEN ARRAY_SIZE(igb_priv_flags_strings)
>> 
>>+static const u8 broadcast_addr[ETH_ALEN] = {
>>+	0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
>
> This is already defined in an existing header, don't have it handy but
> likely etherdevice.h.

Yeah, I didn't find the address definition, but there's a helper to
build a broadcast address, which is just what I need. Thanks.

>
> -- 
> Florian


Cheers,
--
Vinicius

  reply	other threads:[~2018-02-26 19:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-24  1:20 [next-queue PATCH 0/8] igb: offloading of receive filters Vinicius Costa Gomes
2018-02-24  1:20 ` [next-queue PATCH 1/8] igb: Fix not adding filter elements to the list Vinicius Costa Gomes
2018-02-24  1:20 ` [next-queue PATCH 2/8] igb: Fix queue selection on MAC filters on i210 and i211 Vinicius Costa Gomes
2018-02-24  1:20 ` [next-queue PATCH 3/8] igb: Enable the hardware traffic class feature bit for igb models Vinicius Costa Gomes
2018-02-25 22:37   ` [Intel-wired-lan] " Alexander Duyck
2018-02-26 18:49     ` Vinicius Costa Gomes
2018-02-24  1:20 ` [next-queue PATCH 4/8] igb: Add support for MAC address filters specifying source addresses Vinicius Costa Gomes
2018-02-25 22:42   ` [Intel-wired-lan] " Alexander Duyck
2018-02-26 19:24     ` Vinicius Costa Gomes
2018-02-24  1:20 ` [next-queue PATCH 5/8] igb: Add support for ethtool MAC address filters Vinicius Costa Gomes
2018-02-24  4:38   ` Florian Fainelli
2018-02-26 19:30     ` Vinicius Costa Gomes [this message]
2018-02-24  1:20 ` [next-queue PATCH 6/8] igb: Add the skeletons for tc-flower offloading Vinicius Costa Gomes
2018-02-24  1:20 ` [next-queue PATCH 7/8] igb: Add support for adding offloaded clsflower filters Vinicius Costa Gomes
2018-02-24  4:45   ` Florian Fainelli
2018-02-27  0:40     ` Vinicius Costa Gomes
2018-02-27  0:51       ` Florian Fainelli
2018-02-27  1:51         ` Vinicius Costa Gomes
2018-02-26  0:12   ` [Intel-wired-lan] " kbuild test robot
2018-02-24  1:20 ` [next-queue PATCH 8/8] igb: Add support for removing offloaded tc-flower filters Vinicius Costa Gomes
2018-02-24  4:36   ` Florian Fainelli
2018-02-26 20:59     ` 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=874lm3blas.fsf@intel.com \
    --to=vinicius.gomes@intel.com \
    --cc=f.fainelli@gmail.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jesus.sanchez-palencia@intel.com \
    --cc=netdev@vger.kernel.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).