| Message ID | 20180329210751.11531-9-vinicius.gomes@intel.com |
|---|---|
| State | Awaiting Upstream, archived |
| Delegated to: | David Miller |
| Headers | show |
| Series | igb: offloading of receive filters | expand |
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On > Behalf Of Vinicius Costa Gomes > Sent: Thursday, March 29, 2018 2:08 PM > To: intel-wired-lan@lists.osuosl.org > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez- > palencia@intel.com> > Subject: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC > address support for ethtool nftuple filters > > 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) This is now working for me, testing with the dst MAC being the MAC on the i210. I set the filter and all the traffic to the destination MAC address gets routed to the chosen RX queue. > $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3 > (this will direct packets with source address "44:44:44:44:44:44" to > the RX queue 3) However, I am still not getting the raw ethernet source filter to work. Even back to back with no other system to "confuse" the stream, I set the filter so the source MAC is the same as the MAC on the link partner, send traffic and the traffic bounces around the queues as if the filter is not set. > > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> > --- > drivers/net/ethernet/intel/igb/igb_ethtool.c | 35 > ++++++++++++++++++++++++---- > 1 file changed, 31 insertions(+), 4 deletions(-)
Hi, "Brown, Aaron F" <aaron.f.brown@intel.com> writes: >> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On >> Behalf Of Vinicius Costa Gomes >> Sent: Thursday, March 29, 2018 2:08 PM >> To: intel-wired-lan@lists.osuosl.org >> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez- >> palencia@intel.com> >> Subject: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC >> address support for ethtool nftuple filters >> >> 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) > > This is now working for me, testing with the dst MAC being the MAC on the i210. I set the filter and all the traffic to the destination MAC address gets routed to the chosen RX queue. > >> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3 >> (this will direct packets with source address "44:44:44:44:44:44" to >> the RX queue 3) > > However, I am still not getting the raw ethernet source filter to > work. Even back to back with no other system to "confuse" the stream, > I set the filter so the source MAC is the same as the MAC on the link > partner, send traffic and the traffic bounces around the queues as if > the filter is not set. It seems there is at least a documentation issue in the i210 datasheet, steering (placing traffic into a specific queue) by source address doesn't work, filtering (accepting the traffic based on some rule) does work. I pointed this out in the cover letter of v5 as a known issue, but forgot to repeat it for v6, sorry about the confusion. But only the filtering part is useful, I think, it enables cases like this: $ ethtool -N enp2s0 flow-type ether src 68:05:ca:4a:c9:73 proto 0x22f0 action 3 I added that note in the hope that someone else would have an stronger opinion about what to do. Anyway, my plan for now will be to document this better and turn the case that only the source address is specified into an error. > >> >> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> >> --- >> drivers/net/ethernet/intel/igb/igb_ethtool.c | 35 >> ++++++++++++++++++++++++---- >> 1 file changed, 31 insertions(+), 4 deletions(-) Cheers, -- Vinicius
> From: Gomes, Vinicius > Sent: Thursday, April 5, 2018 11:00 AM > To: Brown, Aaron F <aaron.f.brown@intel.com>; intel-wired- > lan@lists.osuosl.org > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez- > palencia@intel.com> > Subject: RE: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC > address support for ethtool nftuple filters > > Hi, > > "Brown, Aaron F" <aaron.f.brown@intel.com> writes: > > >> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On > >> Behalf Of Vinicius Costa Gomes > >> Sent: Thursday, March 29, 2018 2:08 PM > >> To: intel-wired-lan@lists.osuosl.org > >> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez- > >> palencia@intel.com> > >> Subject: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC > >> address support for ethtool nftuple filters > >> > >> 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) > > > > This is now working for me, testing with the dst MAC being the MAC on the > i210. I set the filter and all the traffic to the destination MAC address gets > routed to the chosen RX queue. > > > >> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3 > >> (this will direct packets with source address "44:44:44:44:44:44" to > >> the RX queue 3) Since this apparently does not work without refining the filter down to an ethertype I would like to see this example touched up to include the proto keyword. > > > > However, I am still not getting the raw ethernet source filter to > > work. Even back to back with no other system to "confuse" the stream, > > I set the filter so the source MAC is the same as the MAC on the link > > partner, send traffic and the traffic bounces around the queues as if > > the filter is not set. > > It seems there is at least a documentation issue in the i210 datasheet, > steering (placing traffic into a specific queue) by source address > doesn't work, filtering (accepting the traffic based on some rule) does > work. I pointed this out in the cover letter of v5 as a known issue, but > forgot to repeat it for v6, sorry about the confusion. Yes, I recall that now. I don't think I quite understood the implication at the time, but after trying it out it that makes perfect sense with what I am seeing. > > But only the filtering part is useful, I think, it enables cases like > this: > > $ ethtool -N enp2s0 flow-type ether src 68:05:ca:4a:c9:73 proto 0x22f0 action > 3 Ok, yes, this works. If I tack on the proto keyword I can filter on whatever ethertype I choose and it seems to direct to the queue as expected. > > I added that note in the hope that someone else would have an stronger > opinion about what to do. I don't have a strong opinion beyond my preference for an ideal world where everything works :) If the part simply cannot filter on the src address as a whole without the protocol I would ideally prefer an attempt in ethtool to set the filter on src address as a whole to return an error WHILE still allowing the filter to be set on an ethertype when the proto keyword is issued. If ethtool does not allow that fine grain of control then I think the way it is now is good, I'd rather have the annoyance of being able to set a filter that does nothing then not be able to set the more specific filter at all. > > Anyway, my plan for now will be to document this better and turn the > case that only the source address is specified into an error. > > > > >> > >> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> > >> --- > >> drivers/net/ethernet/intel/igb/igb_ethtool.c | 35 > >> ++++++++++++++++++++++++---- > >> 1 file changed, 31 insertions(+), 4 deletions(-) > > > Cheers, > -- > Vinicius
Hi, "Brown, Aaron F" <aaron.f.brown@intel.com> writes: [...] > >> >> I added that note in the hope that someone else would have an stronger >> opinion about what to do. > > I don't have a strong opinion beyond my preference for an ideal world > where everything works :) If the part simply cannot filter on the src > address as a whole without the protocol I would ideally prefer an > attempt in ethtool to set the filter on src address as a whole to > return an error WHILE still allowing the filter to be set on an > ethertype when the proto keyword is issued. If ethtool does not allow > that fine grain of control then I think the way it is now is good, I'd > rather have the annoyance of being able to set a filter that does > nothing then not be able to set the more specific filter at all. We are agreed. The next version of this series implements just that: specifying the src address alone is an error, but if the classifier has a src address and any other filter, it works. Cheers, -- Vinicius
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c index 31b2960a7869..491946e09f8e 100644 --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c @@ -2495,6 +2495,23 @@ static int igb_get_ethtool_nfc_entry(struct igb_adapter *adapter, fsp->h_ext.vlan_tci = rule->filter.vlan_tci; fsp->m_ext.vlan_tci = htons(VLAN_PRIO_MASK); } + if (rule->filter.match_flags & IGB_FILTER_FLAG_DST_MAC_ADDR) { + ether_addr_copy(fsp->h_u.ether_spec.h_dest, + rule->filter.dst_addr); + /* As we only support matching by the full + * mask, return the mask to userspace + */ + eth_broadcast_addr(fsp->m_u.ether_spec.h_dest); + } + if (rule->filter.match_flags & IGB_FILTER_FLAG_SRC_MAC_ADDR) { + ether_addr_copy(fsp->h_u.ether_spec.h_source, + rule->filter.src_addr); + /* As we only support matching by the full + * mask, return the mask to userspace + */ + eth_broadcast_addr(fsp->m_u.ether_spec.h_source); + } + return 0; } return -EINVAL; @@ -2933,10 +2950,6 @@ static int igb_add_ethtool_nfc_entry(struct igb_adapter *adapter, if ((fsp->flow_type & ~FLOW_EXT) != ETHER_FLOW) return -EINVAL; - if (fsp->m_u.ether_spec.h_proto != ETHER_TYPE_FULL_MASK && - fsp->m_ext.vlan_tci != htons(VLAN_PRIO_MASK)) - return -EINVAL; - input = kzalloc(sizeof(*input), GFP_KERNEL); if (!input) return -ENOMEM; @@ -2946,6 +2959,20 @@ static int igb_add_ethtool_nfc_entry(struct igb_adapter *adapter, input->filter.match_flags = IGB_FILTER_FLAG_ETHER_TYPE; } + /* Only support matching addresses by the full mask */ + if (is_broadcast_ether_addr(fsp->m_u.ether_spec.h_source)) { + input->filter.match_flags |= IGB_FILTER_FLAG_SRC_MAC_ADDR; + ether_addr_copy(input->filter.src_addr, + fsp->h_u.ether_spec.h_source); + } + + /* Only support matching addresses by the full mask */ + if (is_broadcast_ether_addr(fsp->m_u.ether_spec.h_dest)) { + input->filter.match_flags |= IGB_FILTER_FLAG_DST_MAC_ADDR; + ether_addr_copy(input->filter.dst_addr, + fsp->h_u.ether_spec.h_dest); + } + if ((fsp->flow_type & FLOW_EXT) && fsp->m_ext.vlan_tci) { if (fsp->m_ext.vlan_tci != htons(VLAN_PRIO_MASK)) { err = -EINVAL;
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 source address "44:44:44:44:44:44" to the RX queue 3) Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> --- drivers/net/ethernet/intel/igb/igb_ethtool.c | 35 ++++++++++++++++++++++++---- 1 file changed, 31 insertions(+), 4 deletions(-)