netdev - Re: [PATCH 10/12] drivers: PMC MSP71xx ethernet driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <46560E06.9090506@pmc-sierra.com>
Date:	Thu, 24 May 2007 15:13:26 -0700
From:	Marc St-Jean <Marc_St-Jean@...-sierra.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Marc St-Jean <stjeanma@...-sierra.com>, akpm@...ux-foundation.org,
	linux-mips@...ux-mips.org, netdev@...r.kernel.org
Subject: Re: [PATCH 10/12] drivers: PMC MSP71xx ethernet driver

Jeff Garzik wrote:
> Marc St-Jean wrote:
>  > +inline static void
>  > +mspeth_skb_headerinit(struct sk_buff *skb)
>  > +{
>  > +     /* these are essential before init */
>  > +     dst_release(skb->dst);
>  > +#ifdef CONFIG_XFRM
>  > +     secpath_put(skb->sp);
>  > +#endif
>  > +#ifdef CONFIG_NETFILTER
>  > +     nf_conntrack_put(skb->nfct);
>  > +#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
>  > +     nf_conntrack_put_reasm(skb->nfct_reasm);
>  > +#endif
>  > +#ifdef CONFIG_BRIDGE_NETFILTER
>  > +     nf_bridge_put(skb->nf_bridge);
>  > +#endif
>  > +#endif /* CONFIG_NETFILTER */
>  > +
>  > +     /*
>  > +      * Now initialise the skb...
>  > +      * Clear the members till skb->truesize.
>  > +      */
>  > +     memset(skb, 0, offsetof(struct sk_buff, truesize));
>  > +}
>  > +#endif /* CONFIG_MSPETH_SKB_RECYCLE */
> 
> Did you ever resend this driver addition, with the above unmaintainable
> skb init hacks removed?
> 
>         Jeff
> 

I removed the section you originally refererd to as it was associated with the
linux 2.4 support which was also removed.

I asked if the remaining section (above) was acceptable so we could retain our
buffer recycling which enhances throughput. I never received a rely so it was
left in my last patch.

The above comment now answers my part of my initial question. Are you aware of
a better way to implement this or must we lose all our recycling enhancements?

Thanks,
Marc
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html