Network device driver KPI/ABI and TOE

[Kip Macy]

You might want to check out sys/modules/cxgb/tom/Makefile.

 -Kip

On Feb 17, 2008 1:24 PM, Bjoern A. Zeeb <bzeeb-lists at lists.zabbadoz.net> wrote:
> On Sun, 6 Jan 2008, Robert Watson wrote:
>
> Hi,
>
> [cutting a long mail short and randomly replying;-)]
>
> I came across dev/cxgb/ulp/tom/cxgb_tcp_subr.c vs. netinet/tcp_subr.c
> and I am a bit worried with the way things are done atm. For those
> functions copied over there are only changes like:
>
> -                       tp = cxgb_tcp_drop(tp, ECONNABORTED);
> +                       tp = tcp_drop(tp, ECONNABORTED);
>
> -               notify = cxgb_tcp_drop_syn_sent;
> +               notify = tcp_drop_syn_sent;
>
> -               tcp_gen_listen_close(tp);
> +               tcp_offload_listen_close(tp);
>
> -               (void) tcp_gen_reset(tp);
> +               (void) tcp_output_reset(tp);
>
> and SYSCTL stuff.
>
>
> This is a "problem" for following reasons:
> - code duplication
> - if one changes netinet/tcp_subr.c one has to change foo4_tcp_subr.c
>    as well
> - if more drivers are going to implement things that way it'll be
>    even more code duplication.
> - developers will have to check lots of different places they might
>    not expect in first place.
> - those things might interfere with our locking as well.
>
> I assume (without looking) the other files in the tom directory expose
> similar behavior. So this is a more general problem:
>
> we need to seriously think about abstracting our tcp_subr.c (and
> other) functions to avoid this duplication or at least integrate
> things better by other ways.
>
> This is mostly asking networking people to think about this so we can
> iteratively improve things. cxgb has done a good first step in that
> direction, now is the time to further hone things.
>
>
> /bz
>
> --
> Bjoern A. Zeeb                                 bzeeb at Zabbadoz dot NeT
> Software is harder than hardware  so better get it right the first time.
>
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>