| Message ID | 20230824122337.3300895-1-ahmed.zaki@intel.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [iwl-next] iavf: remove "inline" functions from iavf_txrx.c | expand |
From: Ahmed Zaki <ahmed.zaki@intel.com> Date: Thu, 24 Aug 2023 06:23:37 -0600 > From: Jacob Keller <jacob.e.keller@intel.com> > > The iAVF txrx hotpath code has several functions that are marked as > "static inline" in the iavf_txrx.c file. This use of inline is frowned > upon in the netdev community and explicitly marked as something to avoid > in the Linux coding-style document (section 15). > > Even though these functions are only used once, it is expected that GCC > is smart enough to decide when to perform function inlining where > appropriate without the "hint". The compilers sometimes do unexpected things. I wouldn't blindly hope. This means, I'd like to have some objdiff or at least bloat-o-meter output here to prove this commit doesn't hurt. If there are changes in the object code -- then some perf tests as well. > > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> > Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com> > --- > drivers/net/ethernet/intel/iavf/iavf_txrx.c | 43 ++++++++++----------- > 1 file changed, 20 insertions(+), 23 deletions(-) > > diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c b/drivers/net/ethernet/intel/iavf/iavf_txrx.c > index 8c5f6096b002..562dafb89f1d 100644 > --- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c > +++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c > @@ -7,8 +7,7 @@ > #include "iavf_trace.h" > #include "iavf_prototype.h" > > -static inline __le64 build_ctob(u32 td_cmd, u32 td_offset, unsigned int size, > - u32 td_tag) > +static __le64 build_ctob(u32 td_cmd, u32 td_offset, unsigned int size, u32 td_tag) > { > return cpu_to_le64(IAVF_TX_DESC_DTYPE_DATA | > ((u64)td_cmd << IAVF_TXD_QW1_CMD_SHIFT) | > @@ -370,8 +369,7 @@ static void iavf_enable_wb_on_itr(struct iavf_vsi *vsi, > q_vector->arm_wb_state = true; > } > > -static inline bool iavf_container_is_rx(struct iavf_q_vector *q_vector, > - struct iavf_ring_container *rc) > +static bool iavf_container_is_rx(struct iavf_q_vector *q_vector, struct iavf_ring_container *rc) Over 80 chars, as well as in a couple of other places below, please recheck the patch (you're trying to fix checkpatch issues and at the same time introducing new? :D). > { > return &q_vector->rx == rc; > } [...] Thanks, Olek
On 2023-08-24 08:49, Alexander Lobakin wrote: > From: Ahmed Zaki <ahmed.zaki@intel.com> > Date: Thu, 24 Aug 2023 06:23:37 -0600 > >> From: Jacob Keller <jacob.e.keller@intel.com> >> >> The iAVF txrx hotpath code has several functions that are marked as >> "static inline" in the iavf_txrx.c file. This use of inline is frowned >> upon in the netdev community and explicitly marked as something to avoid >> in the Linux coding-style document (section 15). >> >> Even though these functions are only used once, it is expected that GCC >> is smart enough to decide when to perform function inlining where >> appropriate without the "hint". > The compilers sometimes do unexpected things. I wouldn't blindly hope. > This means, I'd like to have some objdiff or at least bloat-o-meter > output here to prove this commit doesn't hurt. > If there are changes in the object code -- then some perf tests as well. OK, I will add a bloat-o-meter in v2 > >> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> >> Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com> >> --- >> drivers/net/ethernet/intel/iavf/iavf_txrx.c | 43 ++++++++++----------- >> 1 file changed, 20 insertions(+), 23 deletions(-) >> >> diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c b/drivers/net/ethernet/intel/iavf/iavf_txrx.c >> index 8c5f6096b002..562dafb89f1d 100644 >> --- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c >> +++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c >> @@ -7,8 +7,7 @@ >> #include "iavf_trace.h" >> #include "iavf_prototype.h" >> >> -static inline __le64 build_ctob(u32 td_cmd, u32 td_offset, unsigned int size, >> - u32 td_tag) >> +static __le64 build_ctob(u32 td_cmd, u32 td_offset, unsigned int size, u32 td_tag) >> { >> return cpu_to_le64(IAVF_TX_DESC_DTYPE_DATA | >> ((u64)td_cmd << IAVF_TXD_QW1_CMD_SHIFT) | >> @@ -370,8 +369,7 @@ static void iavf_enable_wb_on_itr(struct iavf_vsi *vsi, >> q_vector->arm_wb_state = true; >> } >> >> -static inline bool iavf_container_is_rx(struct iavf_q_vector *q_vector, >> - struct iavf_ring_container *rc) >> +static bool iavf_container_is_rx(struct iavf_q_vector *q_vector, struct iavf_ring_container *rc) > Over 80 chars, as well as in a couple of other places below, please > recheck the patch (you're trying to fix checkpatch issues and at the > same time introducing new? :D). ./scripts/checkpatch.pl --strict not showing any errors. No idea why. I will break this and resend. > >> { >> return &q_vector->rx == rc; >> } > [...] > > Thanks, > Olek
On 8/24/23 17:46, Ahmed Zaki wrote: > > On 2023-08-24 08:49, Alexander Lobakin wrote: >> From: Ahmed Zaki <ahmed.zaki@intel.com> >> Date: Thu, 24 Aug 2023 06:23:37 -0600 >> >>> From: Jacob Keller <jacob.e.keller@intel.com> >>> >>> The iAVF txrx hotpath code has several functions that are marked as >>> "static inline" in the iavf_txrx.c file. This use of inline is frowned >>> upon in the netdev community and explicitly marked as something to avoid >>> in the Linux coding-style document (section 15). >>> >>> Even though these functions are only used once, it is expected that GCC >>> is smart enough to decide when to perform function inlining where >>> appropriate without the "hint". >> The compilers sometimes do unexpected things. I wouldn't blindly hope. >> This means, I'd like to have some objdiff or at least bloat-o-meter >> output here to prove this commit doesn't hurt. >> If there are changes in the object code -- then some perf tests as well. > > OK, I will add a bloat-o-meter in v2 > > >> >>> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> >>> Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com> >>> --- >>> drivers/net/ethernet/intel/iavf/iavf_txrx.c | 43 ++++++++++----------- >>> 1 file changed, 20 insertions(+), 23 deletions(-) >>> >>> diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c >>> b/drivers/net/ethernet/intel/iavf/iavf_txrx.c >>> index 8c5f6096b002..562dafb89f1d 100644 >>> --- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c >>> +++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c >>> @@ -7,8 +7,7 @@ >>> #include "iavf_trace.h" >>> #include "iavf_prototype.h" >>> -static inline __le64 build_ctob(u32 td_cmd, u32 td_offset, unsigned >>> int size, >>> - u32 td_tag) >>> +static __le64 build_ctob(u32 td_cmd, u32 td_offset, unsigned int >>> size, u32 td_tag) >>> { >>> return cpu_to_le64(IAVF_TX_DESC_DTYPE_DATA | >>> ((u64)td_cmd << IAVF_TXD_QW1_CMD_SHIFT) | >>> @@ -370,8 +369,7 @@ static void iavf_enable_wb_on_itr(struct iavf_vsi >>> *vsi, >>> q_vector->arm_wb_state = true; >>> } >>> -static inline bool iavf_container_is_rx(struct iavf_q_vector *q_vector, >>> - struct iavf_ring_container *rc) >>> +static bool iavf_container_is_rx(struct iavf_q_vector *q_vector, >>> struct iavf_ring_container *rc) >> Over 80 chars, as well as in a couple of other places below, please >> recheck the patch (you're trying to fix checkpatch issues and at the >> same time introducing new? :D). > > ./scripts/checkpatch.pl --strict not showing any errors. No idea why. I'm using this thanks to Marcin: ./scripts/checkpatch.pl --show-types --codespell --mailback --ignore LONG_LINE_STRING --max-line-length=80 --patch $1 > I will break this and resend. > >> >>> { >>> return &q_vector->rx == rc; >>> } >> [...] >> >> Thanks, >> Olek > _______________________________________________ > Intel-wired-lan mailing list > Intel-wired-lan@osuosl.org > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
On 2023-08-24 09:46, Ahmed Zaki wrote: > > On 2023-08-24 08:49, Alexander Lobakin wrote: >> From: Ahmed Zaki <ahmed.zaki@intel.com> >> Date: Thu, 24 Aug 2023 06:23:37 -0600 >> >>> From: Jacob Keller <jacob.e.keller@intel.com> >>> >>> The iAVF txrx hotpath code has several functions that are marked as >>> "static inline" in the iavf_txrx.c file. This use of inline is frowned >>> upon in the netdev community and explicitly marked as something to >>> avoid >>> in the Linux coding-style document (section 15). >>> >>> Even though these functions are only used once, it is expected that GCC >>> is smart enough to decide when to perform function inlining where >>> appropriate without the "hint". >> The compilers sometimes do unexpected things. I wouldn't blindly hope. >> This means, I'd like to have some objdiff or at least bloat-o-meter >> output here to prove this commit doesn't hurt. >> If there are changes in the object code -- then some perf tests as well. > > OK, I will add a bloat-o-meter in v2 bloat-o-meter is showing zero diff: add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) Function old new delta Total: Before=12166, After=12166, chg +0.00%
On 2023-08-24 14:01, Przemek Kitszel wrote: > On 8/24/23 17:46, Ahmed Zaki wrote: >> >> On 2023-08-24 08:49, Alexander Lobakin wrote: >>> From: Ahmed Zaki <ahmed.zaki@intel.com> >>> Date: Thu, 24 Aug 2023 06:23:37 -0600 >>> >>>> From: Jacob Keller <jacob.e.keller@intel.com> >>>> >>>> The iAVF txrx hotpath code has several functions that are marked as >>>> "static inline" in the iavf_txrx.c file. This use of inline is frowned >>>> upon in the netdev community and explicitly marked as something to >>>> avoid >>>> in the Linux coding-style document (section 15). >>>> >>>> Even though these functions are only used once, it is expected that >>>> GCC >>>> is smart enough to decide when to perform function inlining where >>>> appropriate without the "hint". >>> The compilers sometimes do unexpected things. I wouldn't blindly hope. >>> This means, I'd like to have some objdiff or at least bloat-o-meter >>> output here to prove this commit doesn't hurt. >>> If there are changes in the object code -- then some perf tests as >>> well. >> >> OK, I will add a bloat-o-meter in v2 >> >> >>> >>>> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> >>>> Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com> >>>> --- >>>> drivers/net/ethernet/intel/iavf/iavf_txrx.c | 43 >>>> ++++++++++----------- >>>> 1 file changed, 20 insertions(+), 23 deletions(-) >>>> >>>> diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c >>>> b/drivers/net/ethernet/intel/iavf/iavf_txrx.c >>>> index 8c5f6096b002..562dafb89f1d 100644 >>>> --- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c >>>> +++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c >>>> @@ -7,8 +7,7 @@ >>>> #include "iavf_trace.h" >>>> #include "iavf_prototype.h" >>>> -static inline __le64 build_ctob(u32 td_cmd, u32 td_offset, >>>> unsigned int size, >>>> - u32 td_tag) >>>> +static __le64 build_ctob(u32 td_cmd, u32 td_offset, unsigned int >>>> size, u32 td_tag) >>>> { >>>> return cpu_to_le64(IAVF_TX_DESC_DTYPE_DATA | >>>> ((u64)td_cmd << IAVF_TXD_QW1_CMD_SHIFT) | >>>> @@ -370,8 +369,7 @@ static void iavf_enable_wb_on_itr(struct >>>> iavf_vsi *vsi, >>>> q_vector->arm_wb_state = true; >>>> } >>>> -static inline bool iavf_container_is_rx(struct iavf_q_vector >>>> *q_vector, >>>> - struct iavf_ring_container *rc) >>>> +static bool iavf_container_is_rx(struct iavf_q_vector *q_vector, >>>> struct iavf_ring_container *rc) >>> Over 80 chars, as well as in a couple of other places below, please >>> recheck the patch (you're trying to fix checkpatch issues and at the >>> same time introducing new? :D). >> >> ./scripts/checkpatch.pl --strict not showing any errors. No idea why. > > I'm using this thanks to Marcin: > ./scripts/checkpatch.pl --show-types --codespell --mailback --ignore > LONG_LINE_STRING --max-line-length=80 --patch $1 yep, that is doing it. I guess "strict" is not that strict after all :) Thanks, Ahmed
From: Ahmed Zaki <ahmed.zaki@intel.com> Date: Thu, 24 Aug 2023 14:08:05 -0600 > > On 2023-08-24 09:46, Ahmed Zaki wrote: >> >> On 2023-08-24 08:49, Alexander Lobakin wrote: >>> From: Ahmed Zaki <ahmed.zaki@intel.com> >>> Date: Thu, 24 Aug 2023 06:23:37 -0600 >>> >>>> From: Jacob Keller <jacob.e.keller@intel.com> >>>> >>>> The iAVF txrx hotpath code has several functions that are marked as >>>> "static inline" in the iavf_txrx.c file. This use of inline is frowned >>>> upon in the netdev community and explicitly marked as something to >>>> avoid >>>> in the Linux coding-style document (section 15). >>>> >>>> Even though these functions are only used once, it is expected that GCC >>>> is smart enough to decide when to perform function inlining where >>>> appropriate without the "hint". >>> The compilers sometimes do unexpected things. I wouldn't blindly hope. >>> This means, I'd like to have some objdiff or at least bloat-o-meter >>> output here to prove this commit doesn't hurt. >>> If there are changes in the object code -- then some perf tests as well. >> >> OK, I will add a bloat-o-meter in v2 > > bloat-o-meter is showing zero diff: > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > Function old new delta > Total: Before=12166, After=12166, chg +0.00% Ack. Add it to the commit message please. But before that, please check the same with Clang. And don't forget that we have CC_OPTIMIZE_FOR_PERFORMANCE and CC_OPTIMIZE_FOR_SIZE and ideally I'd like you to test both GCC and Clang on both of them, since they pass different `-Ox` flags and results may sometimes vary a lot (`-Os` inlines stuff less aggressively). Thanks, Olek
On 2023-08-25 05:36, Alexander Lobakin wrote: > From: Ahmed Zaki <ahmed.zaki@intel.com> > Date: Thu, 24 Aug 2023 14:08:05 -0600 > >> On 2023-08-24 09:46, Ahmed Zaki wrote: >>> On 2023-08-24 08:49, Alexander Lobakin wrote: >>>> From: Ahmed Zaki <ahmed.zaki@intel.com> >>>> Date: Thu, 24 Aug 2023 06:23:37 -0600 >>>> >>>>> From: Jacob Keller <jacob.e.keller@intel.com> >>>>> >>>>> The iAVF txrx hotpath code has several functions that are marked as >>>>> "static inline" in the iavf_txrx.c file. This use of inline is frowned >>>>> upon in the netdev community and explicitly marked as something to >>>>> avoid >>>>> in the Linux coding-style document (section 15). >>>>> >>>>> Even though these functions are only used once, it is expected that GCC >>>>> is smart enough to decide when to perform function inlining where >>>>> appropriate without the "hint". >>>> The compilers sometimes do unexpected things. I wouldn't blindly hope. >>>> This means, I'd like to have some objdiff or at least bloat-o-meter >>>> output here to prove this commit doesn't hurt. >>>> If there are changes in the object code -- then some perf tests as well. >>> OK, I will add a bloat-o-meter in v2 >> bloat-o-meter is showing zero diff: >> >> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) >> Function old new delta >> Total: Before=12166, After=12166, chg +0.00% > Ack. Add it to the commit message please. But before that, please check > the same with Clang. And don't forget that we have > CC_OPTIMIZE_FOR_PERFORMANCE and CC_OPTIMIZE_FOR_SIZE and ideally I'd > like you to test both GCC and Clang on both of them, since they pass > different `-Ox` flags and results may sometimes vary a lot (`-Os` > inlines stuff less aggressively). I already added a comment in v2 about the bloat-o-meter result. I had my system on "-O2" (above results), changed that to "Os", rebuilt modules and I got same Zero diff result (expected since not much inlining). Thanks, Ahmed
From: Ahmed Zaki <ahmed.zaki@intel.com> Date: Fri, 25 Aug 2023 09:31:38 -0600 > > On 2023-08-25 05:36, Alexander Lobakin wrote: >> From: Ahmed Zaki <ahmed.zaki@intel.com> >> Date: Thu, 24 Aug 2023 14:08:05 -0600 >> >>> On 2023-08-24 09:46, Ahmed Zaki wrote: >>>> On 2023-08-24 08:49, Alexander Lobakin wrote: >>>>> From: Ahmed Zaki <ahmed.zaki@intel.com> >>>>> Date: Thu, 24 Aug 2023 06:23:37 -0600 >>>>> >>>>>> From: Jacob Keller <jacob.e.keller@intel.com> >>>>>> >>>>>> The iAVF txrx hotpath code has several functions that are marked as >>>>>> "static inline" in the iavf_txrx.c file. This use of inline is >>>>>> frowned >>>>>> upon in the netdev community and explicitly marked as something to >>>>>> avoid >>>>>> in the Linux coding-style document (section 15). >>>>>> >>>>>> Even though these functions are only used once, it is expected >>>>>> that GCC >>>>>> is smart enough to decide when to perform function inlining where >>>>>> appropriate without the "hint". >>>>> The compilers sometimes do unexpected things. I wouldn't blindly hope. >>>>> This means, I'd like to have some objdiff or at least bloat-o-meter >>>>> output here to prove this commit doesn't hurt. >>>>> If there are changes in the object code -- then some perf tests as >>>>> well. >>>> OK, I will add a bloat-o-meter in v2 >>> bloat-o-meter is showing zero diff: >>> >>> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) >>> Function old new delta >>> Total: Before=12166, After=12166, chg +0.00% >> Ack. Add it to the commit message please. But before that, please check >> the same with Clang. And don't forget that we have >> CC_OPTIMIZE_FOR_PERFORMANCE and CC_OPTIMIZE_FOR_SIZE and ideally I'd >> like you to test both GCC and Clang on both of them, since they pass >> different `-Ox` flags and results may sometimes vary a lot (`-Os` >> inlines stuff less aggressively). > > I already added a comment in v2 about the bloat-o-meter result. I had my > system on "-O2" (above results), changed that to "Os", rebuilt modules > and I got same Zero diff result (expected since not much inlining). Ack, thanks. > > Thanks, > > Ahmed > Olek
diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c b/drivers/net/ethernet/intel/iavf/iavf_txrx.c index 8c5f6096b002..562dafb89f1d 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c +++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c @@ -7,8 +7,7 @@ #include "iavf_trace.h" #include "iavf_prototype.h" -static inline __le64 build_ctob(u32 td_cmd, u32 td_offset, unsigned int size, - u32 td_tag) +static __le64 build_ctob(u32 td_cmd, u32 td_offset, unsigned int size, u32 td_tag) { return cpu_to_le64(IAVF_TX_DESC_DTYPE_DATA | ((u64)td_cmd << IAVF_TXD_QW1_CMD_SHIFT) | @@ -370,8 +369,7 @@ static void iavf_enable_wb_on_itr(struct iavf_vsi *vsi, q_vector->arm_wb_state = true; } -static inline bool iavf_container_is_rx(struct iavf_q_vector *q_vector, - struct iavf_ring_container *rc) +static bool iavf_container_is_rx(struct iavf_q_vector *q_vector, struct iavf_ring_container *rc) { return &q_vector->rx == rc; } @@ -806,7 +804,7 @@ int iavf_setup_rx_descriptors(struct iavf_ring *rx_ring) * @rx_ring: ring to bump * @val: new head index **/ -static inline void iavf_release_rx_desc(struct iavf_ring *rx_ring, u32 val) +static void iavf_release_rx_desc(struct iavf_ring *rx_ring, u32 val) { rx_ring->next_to_use = val; @@ -828,7 +826,7 @@ static inline void iavf_release_rx_desc(struct iavf_ring *rx_ring, u32 val) * * Returns the offset value for ring into the data buffer. */ -static inline unsigned int iavf_rx_offset(struct iavf_ring *rx_ring) +static unsigned int iavf_rx_offset(struct iavf_ring *rx_ring) { return ring_uses_build_skb(rx_ring) ? IAVF_SKB_PAD : 0; } @@ -977,9 +975,9 @@ bool iavf_alloc_rx_buffers(struct iavf_ring *rx_ring, u16 cleaned_count) * @skb: skb currently being received and modified * @rx_desc: the receive descriptor **/ -static inline void iavf_rx_checksum(struct iavf_vsi *vsi, - struct sk_buff *skb, - union iavf_rx_desc *rx_desc) +static void iavf_rx_checksum(struct iavf_vsi *vsi, + struct sk_buff *skb, + union iavf_rx_desc *rx_desc) { struct iavf_rx_ptype_decoded decoded; u32 rx_error, rx_status; @@ -1061,7 +1059,7 @@ static inline void iavf_rx_checksum(struct iavf_vsi *vsi, * * Returns a hash type to be used by skb_set_hash **/ -static inline int iavf_ptype_to_htype(u8 ptype) +static int iavf_ptype_to_htype(u8 ptype) { struct iavf_rx_ptype_decoded decoded = decode_rx_desc_ptype(ptype); @@ -1085,10 +1083,10 @@ static inline int iavf_ptype_to_htype(u8 ptype) * @skb: skb currently being received and modified * @rx_ptype: Rx packet type **/ -static inline void iavf_rx_hash(struct iavf_ring *ring, - union iavf_rx_desc *rx_desc, - struct sk_buff *skb, - u8 rx_ptype) +static void iavf_rx_hash(struct iavf_ring *ring, + union iavf_rx_desc *rx_desc, + struct sk_buff *skb, + u8 rx_ptype) { u32 hash; const __le64 rss_mask = @@ -1115,10 +1113,10 @@ static inline void iavf_rx_hash(struct iavf_ring *ring, * order to populate the hash, checksum, VLAN, protocol, and * other fields within the skb. **/ -static inline -void iavf_process_skb_fields(struct iavf_ring *rx_ring, - union iavf_rx_desc *rx_desc, struct sk_buff *skb, - u8 rx_ptype) +static void +iavf_process_skb_fields(struct iavf_ring *rx_ring, + union iavf_rx_desc *rx_desc, struct sk_buff *skb, + u8 rx_ptype) { iavf_rx_hash(rx_ring, rx_desc, skb, rx_ptype); @@ -1662,8 +1660,7 @@ static inline u32 iavf_buildreg_itr(const int type, u16 itr) * @q_vector: q_vector for which itr is being updated and interrupt enabled * **/ -static inline void iavf_update_enable_itr(struct iavf_vsi *vsi, - struct iavf_q_vector *q_vector) +static void iavf_update_enable_itr(struct iavf_vsi *vsi, struct iavf_q_vector *q_vector) { struct iavf_hw *hw = &vsi->back->hw; u32 intval; @@ -2275,9 +2272,9 @@ int __iavf_maybe_stop_tx(struct iavf_ring *tx_ring, int size) * @td_cmd: the command field in the descriptor * @td_offset: offset for checksum or crc **/ -static inline void iavf_tx_map(struct iavf_ring *tx_ring, struct sk_buff *skb, - struct iavf_tx_buffer *first, u32 tx_flags, - const u8 hdr_len, u32 td_cmd, u32 td_offset) +static void iavf_tx_map(struct iavf_ring *tx_ring, struct sk_buff *skb, + struct iavf_tx_buffer *first, u32 tx_flags, + const u8 hdr_len, u32 td_cmd, u32 td_offset) { unsigned int data_len = skb->data_len; unsigned int size = skb_headlen(skb);