Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1197205 > unrolled thread
| Started by | Florian Fainelli <f.fainelli@gmail.com> |
|---|---|
| First post | 2015-07-31 19:10 +0200 |
| Last post | 2015-07-31 19:10 +0200 |
| Articles | 1 — 1 participant |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH net-next 0/3] net: Switch tag HW extraction/insertion Florian Fainelli <f.fainelli@gmail.com> - 2015-07-31 19:10 +0200
| From | Florian Fainelli <f.fainelli@gmail.com> |
|---|---|
| Date | 2015-07-31 19:10 +0200 |
| Subject | Re: [PATCH net-next 0/3] net: Switch tag HW extraction/insertion |
| Message-ID | <pSlYL-3G7-41@gated-at.bofh.it> |
On 30/07/15 23:08, Eric Dumazet wrote: > On Thu, 2015-07-30 at 18:51 -0700, Florian Fainelli wrote: >> On 30/07/15 15:51, David Miller wrote: >>> From: David Miller <davem@davemloft.net> >>> Date: Thu, 30 Jul 2015 14:19:35 -0700 (PDT) >>> >>>> This looks fine, series applied, thanks. >>> >>> I think your control block is too large, you'll need to rework this >>> somehow. >> >> So napi_gro_cb really is 48 bytes on 64-bits architectures (had not >> realized it was so big). >> >> What would you recommend to do here considering that this driver is >> currently used on 32-bits platforms, but I see no reason why someone >> would no want to use this feature on a 64-bit platform, yet we are >> competing with napi_gro_cb, and adding a new skbuff member is pretty >> much a no-no? Would it be acceptable to have a new member which is ifdef >> CONFIG_NET_DSA_TAG_BRCM? >> >> FWIW, this does provide a small 2-3% throughput increase for RX. > > Which layer will read this tag after GRO processing ? DSA would read this tag, but in general any ethertype hook using packet_type would be in the same boat. > > It seems you simply can use skb->cb[] like other layers : At offset 0. > > BTW brcm_tag_rcv() does not even use GRO, as it calls > netif_receive_skb() That is right here, we will come from the RX processing of a driver that might use napi_gro_receive, as it turns out the sequence looks like this here: bcm_sysport_desc_rx() -> extract tag eth_type_trans() sets skb->protocol to ETH_P_XDSA napi_gro_receive(), sets skb->cb to napi_gro_cb -> walk the list of packet_type find the one for ETH_P_XDSA -> brcm_tag_rcv() BTW, there is no build time assertion that napi_gro_cb is not exceeding skb->cb right now, even though they both have the same size on 64-bits, should we have one? -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to top | Article view | linux.kernel
csiph-web